DESCRIPTION AND THEORETICAL ANALYSIS (USING SCHEMATA) OF 

PLANNER: 
A LANGUAGE FOR PROVING THEOREMS AND 
MANIPULATING MODELS IN A ROBOT 

Carl Hewitt 

April 1972 



ARTIFICIAL INTELLIGENCE LABORATORY 

: " ■ ■ '.;', . ""'' ■• *'3C£A.'' : ' '':'•'■ - • 
MASSACHUSETTS INSTITUTE OF TECHNOLOGY 

/V £.; yy.f..., ... ... 

Cambridge Massachusetts 02139 



Work reported herein was conducted at the Artificial Intelligence Lab- 
oratory, a Massachusetts Institute of Technology research program sup- 
ported in part by the Advanced Research Projects Agency of the Depart- 
ment of Defense and monitored by the Office of Naval Research under 
Contract Number N006l4-70-A-0362-0003. 



The views and conclusions contained in this document are those of the 
author's and should ijat be interpreted as necessarily representing 
the official policies, either expressed or implied, of the Advanced 
Research Projects Agency or the U.S. Government. 



DESCRIPTION AND THEORETICAL ANALYSIS (USING SCHEMATA) OF 

PLANNER: 
A LANGUAGE FOR PROVING THEOREMS AND 
MANIPULATING MODELS IN A ROBOT* 

Abstract 

PLANNER is a formalism for proving theorems and manipulating models 
in a robot. The formalism is built out of a number of problem-solving 
primitives together with a hierarchical multiprocess backtrack control 
structure. Statements can be asserted and perhaps later withdrawn as 
the state of the world changes. Under BACKTRACK control structure, the 
hierarchy of activations of functions previously executed is maintained 
so that it is possible to revert to any previous state. Thus programs 
can easily manipulate elaborate hypothetical tentative states. In addi- 
tion PLANNER uses multiprocessing so that there can be multiple loci of 
control over the problem- solving. Conclusions can be drawn from the various 
changes in state. Goals can be established and dismissed when they are 
satisfied. The deductive system of PLANNER is subordinate to the hier- 
archical control structure in order to maintain the desired degree of 
control. The use of a general -purpose matching language as the basis 
of the deductive system increases the flexibility of the system. Instead 
of explicitly naming procedures in calls, procedures can be invoked im- 
plicitly by patterns of what the procedure is supposed to accomplish. 
The language is being applied to solve problems faced by a robot, to 
write special purpose routines from goal oriented language, to express 
and prove properties of procedures, to abstract procedures from proto- 
cols of their actions, and as a semantic base for English. 

Thesis Supervisor: Seymour Papert, Professor of Mathematics 



♦This report reproduces a thesis of the same title submitted to the 
Department of Mathematics, Massachusetts Institute of Technology, 
on January 29, 1971 in partial fulfillment of the requirements for 
the degree of Doctor of Philosophy. 
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Dote to the fieader 



This paper is organized in what purports to be a logical 
systeaatic fashion. The organization lakes it difficult to get a 
quick over view. The reader should not try to read the paper in a 
linear fashion fron cover to cover. If he gets stuck he should "pop 
up" one level and continue. 

"100 HAVE BEBH BABNED" 

There is an index of praiaitives at the end. There is an index to the 
syntax after the function BEAD. The following guide is provided for 
those readers who are not interested in reading the vhcle paper. 
Chapter 1 is a "hack". Chapter 2 gives the episteiological 
foundations for our approach to problea solving. Chapter 3 is a 
discursive overview of the rest of the thesis using exaaples of some 
features of the problei solving language PL AIM EH. Many of the 
i sport ant ideas in the thesis are touched on soaewhere in the chapter. 
In chapter 4 we find a detailed explanation of the structural pattern 
matching language HATCHLESS. Beaders who are only peripherally 
interested in pattern watching need read only sections 4.1 # 4.2, 4.3, 
and 4.4. Chapter 5 begins the systematic explanation of PLA8HEB. It 
introduces the primitives, data structure, and control structure of 
the language. In contrast to the quantif icational calculus, the 
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semantics of PLAHIBB are expressed in terms of the properties of the 
procedures which define the formalism* In chapter 7 we explain hov 
properties of fl&HBEfi procedures can be expressed and proved is the 
formalism itself* Also we attacJt the problem of hov it is possible to 
teach a problem solver new knowledge* lie explain how schemata give 
the beginning of a theory on the comparative problem solving power of 
various computational models in chapter 8# 
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1. What Achilles Said To The Tortoise 

Lewis Carroll 



Achilles had overtaken the Tortoise, and had seated hiaself 
coafortably on its back, 

"So you've get to the end of our race-course?" said the 
Tortoise ♦ "Even though it does consist of an infinite series of 
distances? I thought some viseacre or other had proved that the 
thing couldn f t be done?" 

"It can be done," said Achilles. "It has teen done! Solvitur 
aabulando. You see the distances were constantly diminishing: and so- 
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"But if they had been constantly increasing?" the Tortoise 
interrupted. "Hon then?" 

"Then I shouldn f t be here," Achilles modestly replied; "and 
you would have got several tines round the world, by this tine!" 

"Tou flatter ae — flatten, I mean," said the Tortoise; "For 
you are a heavy weight, and no sistaJce! lell now, would you like to 
hear of a race-course, that lost people fancy they can get to the end 
of in two or three steps, while it really consists of an infinite 
number of distances, each one longer than the previous one?" 

"Very much indeed!" said the Grecian warrior, as he drew from 
his helmet (few Grecian warriors possessed pockets in those days) an 
enormous note-book and a pencil. "Proceed! And speak slowly, please! 
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Short-hand isn f t invented yet!" 

"That beautiful First proposition of Euclid!" the Tortoise 
murmured dreamily. "Ycu admire Euclid?" 

"Passionately! So far, at least, as one can admire a treatise 
that won't be published for some centuries to come!" 

"Well, now, let's take a little bit of the argument in that 
First Proposition — just two steps, and the conclusion drawn from them. 
Kindly enter them in your note-book. And, in order to refer to them 
conveniently, let's call them A, B, and Z: 

(A) Things that are equal to the same are equal to each other. 

(B) The two sides of this Triangle are things that are equal 
to the same. 

(Z) The two sides of this Triangle are equal to each other. 

"Headers of Euclid will grant, I suppose, that Z follows 
logically from A and B, so that any one who accepts A and B as true, 
must accept Z as true?" 

"Undoubtedly! The youngest child in a High School — as soon as 
High Schools are invented, which will not be till seme two thousand 
years later — will grant that." 

"And if some reader had not yet accepted A and E as true, he 
might still accept the Sequence as a valid one, I suppose?" 

"No doubt such a reader might exist. He might say f I accept 
as true the Hypothetical Proposition that, if A and B be true, Z must 
be true; but I don't accept A and B as true. 1 Such a reader would do 
wisely in abandoning Euclid, and taking to football." 
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"And light there not also be scie reader who would say 'I 

accept A and B as true, but I don't accept the Hypothetical'?" 
"Certainly there Bight. He, also, had better take to 

foot tall." 

"And neither of these readers," the Tortoise continued, "is as 
yet under any logical necessity to accept Z as true?" 

"Quite so," Achilles assented. 

"Bell, now, I want you to consider ae as a reader of the 
second kind, and to force ae, logically, to accept 2 as true." 

"A tortoise playing football would be — " Achilles was 
beginning. 

" — an anoaaly, of course," the Tortoise hastily interrupted, 
"don't wander froa the point. Let's have 2 first, and football 
afterwards!" 

"I'a to force you to accept 2, aa I?" Achilles said ausingly. 
"And your present position is that you accept A and B, but you don't 
accept the Hypothetical — " 

"Let's call it C," said the Tortoise. 

" — but you don't accept: 

(C) If A and E are true, 2 Bust be true." 

"That is ay present posit on," said the Tortoise. 

"Then I aust ask you to accept C." 

"I'll do so," said the Tortoise, "as soon as you've entered it 
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in that note-book of yours. Bhat else have you got in it?" 

"Only a few teeoranda," said Achilles, nervously fluttering 

the leaves: "a few ttensoranda of — of the battles in which I have 

distinguished myself!" 

"Plenty of blank leaves, I see!" the Tortoise cheerily 

reoarked. "We shall need them all!" (Achilles shuddered.) "How write 

as I dictate: 

(A) Things that are egual to the sane are equal each other. 

(B) The two sides of this triangle are things that are egual 
to the same. 

(C) If A and B are true, Z must be true. 

(Z) The two sides of this Triangle are egual to each other." 

"You should call it D, not Z," said Achilles. «It comes next 
to the other three. If you accept A and B and C, you lust accept Z." 

"And why oust I?" 

"Because it follows logically from them. If A and B and C are 
true, Z oust be true. You don't dispute that, I imagine?" 

"If A and B and C are true, Z must be true," the Tortoise 
thoughtfully repeated. "That's another Hypothetical isn't it? And, 
if I failed to see its truth, I might accept A and B and C, and still 
not accept Z, mightn't I?" 

"You might ,» the candid hero admitted; "though such obtuseness 
would certainly be phenomenal. Still, the event is possible. So I 
must ask you to grant one more Hypothetical." 

"Very good. I'm quite willing to grant Z, as soon as you've 
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written it down. We will call it 

(D) If A and B and C are true, Z murt be true. 

"Have you entered that in your note-book?" 
"I have!" Achilles joyfully exclaiaed, as he ran the pencil 
into its sheath. "And at last we've got to the end of this ideal 
race-course! How that you accept A and B and c and D, of course you 
accept z." 

"Do I?" said the Tortoise innocently. "Let's ■ake that quite 
clear. I accept A and B and C and D. Suppose I still refuse to 
accept z?" 

"Then Logic would take you by the throat, and force yon to do 
it!" Achilles triumphantly replied. "Logic would tell you can't help 
yourself. now that you've accepted A and B and c and D, you «ust 
accept Z!» So you've no choice, you see." 

"Whatever Logic is good enough to tell me is worth writing 
down," said the Tortoise. "So enter it in your book, please. Be will 
call it 

(E) If A and B and c and D are true, z sust be true. 

"Until I've granted that, of course, I needn't grant 2, So 
it's quite a necessary step, you see?" 

"I see," said Achilles; and there was a touch of sadness in 
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his tone. 
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2. The Structural Foundations of Problea Solving 



He would like to develop a foundation for problea solving 
analogous in soae nays to the currently existing foundations for 
aatheaatics. Thus ve need to analyze the structure of foundations 
for aatheaatics. A foundation for aatheaatics aust provide a 
definitional foraalisa in which aatheaatical objects can be defined 
and their existence proved. For example set theory as a foundation 
provides that objects aust be built out of sets. Then there aust be a 
deductive foraalisa in which fundaaental truths can be stated and the 
y^-v Beans provided to deduce additional truths froa those already 

established. Current aatheaatical foundations such as set theory 
seen quite natural and adequate for the vast body of classical 
aatheaatics. The objects and reasoning of aost aatheaatical doaains 
such as analysis and algebra can be easily founded on set theory. The 
existence of certain astroncaically large cardinals poses soae 
probleas for set theoretic foundations. However, the probleas posed 
seea to be of practical iaportance only to certain category theorists. 
Foundations of aatheaatics have devoted a great deal of attention to 
the probleas of consistency and coapleteness. The problea of 
consistency is iaportant since if the foundations are inconsistent 
then any for aula whatsoever aay be deduced # thus trivializing the 
foundations. Seaantics for foundations of aatheaatics are defined 
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model theoretically in terms of the notion of satisfiability. The 
problei of completeness, is that for a foundation of mathematics to be 
intuitively satisfactory all the true formulas should be proveable 
since a foundation for mathematics aias to be a theory of mathematical 
truth. 

Similar fundamental questions must be faced by a foundation 
for problem solving. However there are some important differences 
since a foundation for problem solving aims more to be a theory of 
actions and purposes than a theory of mathematical truth. A 
foundation for problem solving must specify a goal-oriented formalism 
in which problems can be stated. Furthermore there must be a 
formalism for specifying the allowable methods of solution. As part 
of the definition of the formalisms, the following elements must be 
defined: the data structure, the control structure, and the 
primitive procedures. Being a theory of actions, a foundation for 
problem solving must confront the problem of change: How <tan account 
be taken of the changing situation in the world? In order for there 
to be problem solving, there must be an active agent called a problem 
solver. A foundation for problem solving must consider how much 
knowledge and what kind of knowledge problem solvers can have about 
themselves. In contrast to the foundation of mathematics, the 
semantics for a foundation for problem solving should be defined in 
terms of properties of procedures. le would like to see mathematical 
investigations on the adequacy of the foundations for problem solving 
provided by P1ABHBB. In chapter 8 we have begun one kind of such an 
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investigation. 

To be more specific, a foundation for problem solving must 
concern itself with the following complex of topics: 

PROCEDURAL IMBEDDING: How can "real world" knowledge be 
effectively embedded in procedures. Hhat are good ways to express 
problem solution methods and how can plans for the solution of 
problems be formulated? 

GENERALIZED COMPILATION: shat are good methods for transforming 
hxgh level goal-oriented language into efficient algorithms. 

VERIFICATION: How can it be verified that a procedure does what 
xs intended. 

PROCEDORAL ABSTRACTION: Dhat are good methods for abstracting 
general procedures from special cases. 

One formulation of a foundation for problem solving requires 
that there should be two distinct formalisms: 

1: A METHODS formalism which specifies the allowable methods of 
solution 

2: A PROBLEM SPECIFICATION formalism in which to pose problems. 
The problem solver is expected to figure out how to combine its 
available methods in order to produce a solution which satisfies the 
problem specification. One of the aims of the above formulation of 
problem solving is to clearly separate the methods of solution from 
the problems posed so that it is impossible to "cheat" and give the 
problem solver the methods for solving the problem along with the 
statement of the problem, le propose to bridge the chasm between the 
methods formalism and the problem formalism. Consider more carefully 
the two extremes in the specification of processing: 
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kz Explicit processing (e.g. methods) is the ability to specify 
and control actions down to the finest details, 

B: Implicit processing (e.g. problems) is the ability to specify 
the ena result desired and not to say much about how it should be 

achieved. 
PLAHMEB attempts to provide a formalism in which a problem solver can 
bridge the continuum between explicit and implicit processing. He aim 
for a maximum of flexibility so that whatever knowledge is available 
can be incorporated, even if it is fragmentary and heuristic. 

PLAHNEB is a high level, goal-oriented formalism in which one 
can specify to a large degree what one wants done rather than how to 
do it. Hany o* th<> primitives in PLAR8EB are concerned with 
manipulating a data base in a pattern directed fashion. Most of the 
primitives have been developed as extensions to the formalism when we 
have found problems that could not otherwise be solved in a natural 
way. Of course the trick is to incorporate the new primitive as a 
genuine extension of wide applicability. Others have suggested 
themselves as adjuncts in order to obtain useful closure properties in 
the formalism. Be would be grateful to any reader who could suggest 
problems that would seem to xeguire ftrther extensions or 
modifications to the formalism. 

There are many ways in which one can approach a description of 
PLAHMEB. In this section we will describe PLANNER from an Information 
Processing viewpoint. To do this we will describe the data structure 
and the control structure of the formalism. 
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State 1 

CABOVE AB3 is in the data 

base of state! 



State 3 



State 2 



PLANNER ALLOWS FOR THE SIMULTANEOUS 
EXISTENCE OF INCOMPATIBLE LOCAL STATES 
IN MODELS. 
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DATA STBOCTOBE: 



GfiAPH HEHOEY forms the basis for PLANNEB* s data space which 
consists of directed graphs with labeled arcs* The operation 
of POTTING and GETTING the components of data objects have 
been generalized to apply to any data type whatsoever. For 
example to POT the value CANONICAL on the expression <♦ X Y <* 
X Z>> under the indicator SIfiPXIFIED is one way to record that 
<♦ X Y <* X 2>> has been canonically simplified* Then the 
degree to which an expression is simplified can be determined 
by GETTING the value under the indicator SIMPLIFIED of the 
expression. The operations of POT and GET can be implemented 
efficiently using hash coding* Lists and vectors have been 
introduced to gain more efficiency for common special purpose 
structures. The graph memory is useful to PLANNER in many 
ways. Monitoring gives PLANNER the capability of trapping 
all read, write, and execute references to a particular data 
object* The ponitor (which is found under the indicator 
HCNITOB) of the data object can then take any action that it 
sees fit in order to handle the situation. The graph memory 
can be used to retrieve the value of an identifier i of a 
process p by GETTING the i component of p. Code can be 
commented by simply POTTING the actual comment under the 
indicator COHHENT. Also graph memory enables unique copies of 
structures to be efficiently and conveniently stored* 

DATA BASE: Hhat is most distinctive about the way in which 
PLANNEB uses data is that it has a data base in wnich data can 
be inserted and removed. For example inserting [AT B1 P2 ] 
into the data base might signify that block B1 is at the place 
P2. A coordinate of an expression is defined to be an atom in 
some position* An expression is determined by its 
coordinates* Assertions are stored in buckets by their 
coordinates using the graph memory in order to provide 
efficient retrieval* In addition a total ordering is imposed 
on the assertions so that the buckets can be sorted* 
Imperatives as well as declaratives can be stored in the data 
base* He might assert that whenever an expression of the 
form [AT objectl placel ] is removed from the data base, then 
any expression in the data base of the fori [CN objectl 
object2] should also be removed from the data base* The data 
base can be tree structured so that it is possible to 
simultaneously have several local data bases which are 
incompatible* Furthermore assertions in the data base can 
have varying scopes so that some will last the duration of a 
process while ethers are temporary to a subroutine* 

CONTBOL STBOCTOBE: PLANNEB uses a pattern directed multiprocess 
backtrack control structure to tie the operation of its primitives 
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together. 

BACKTRACKING: PLAHHEB processes have the capability of 
backtracking tc previous states* A process can backtrack into 
a procedure activation (i.e. a specific instance of an 
invocation of a procedure) which has already returned with a 
result* Using the theory of comparative schematology, **? 
have proved in chapter 8 that the use of backtrack control 
enables us to achieve effects that a language (such as LISP) 
which is limited to recursive control cannot achieve. 
Backtracking preserves the nesting of the subroutine structure 
of PLAHHEB while allowing the consequences of elaborate 
tentative hypotheses to be explored without losing the 
capability of rejecting the hypotheses and all of their 
consequences. A choice can be made on the basis of the 
available knowledge and if it doesn f t work, a better choice 
can be made using the new information discovered while 
investigating the first choice. Also backtrack control makes 
PLAHHEB procedures easier to debug since they can be ruu 
backwards as well as forwards enabling a problem solver to 
"zero in" on bugs. 

M01TIPB0CESSING gives PLAHHEB the capability of having more 
/-v than one locus of control in problem solving. By using 

multiple processes, arbitrary patterns of investigation 
through a conceptual problem space can be carried out. 
Processes can have the power to create, read, write, 
interrupt, resume, single step, and fork other processes. The 
ability to single-step or to interrupt processes allows the 
definition of procedures which are HOT monotone in the sense 
of lattice theory. Potentially the failure of monotonicity is 
a serious flaw in the lattice theoretic approach towards a 
mathematical foundation for effective procedures. 

PATTIHh DIBECTIOH combines aspects of control and data strmrture. 
The fundamental principle of pattern directed computation is that 
a procedure should be a pattern of *hat the procedure is intended 
to accomplish. In other words a procedure should not only do the 
right thing but it should appear to do the right thing as well! 
PLAHHEB uses pattern direction for the following operations: 

COHSTBOCTION of structured data objects is accomplished by 
templates. He can construct a list whose first element is 
the value of x and whose second element is the value of y by 
the procedure (x y) . If x has the value 3 and y has the value 
(A B) then (x y) will evaluate to (3 (A B) ) . 

DECOHPOSITIOH is accomplished by matching the data object 
against a structured pattern. If the pattern (x1 x2) is 
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matched against the data object <(3 **) A) then x1 Mill be 
given the value (3 4) ana x2 will be given the value A. 

RETRIEVAL: An assertion is retrieved from the data base by 
specifying a pattern which the assertion aust Batch and 
thereby bind the identifiers in the pattern. For example we 
can determine if there is anything in the data base of the 
for* [CH x A]. If [OB B A] is the only item in the data base, 
then x is bound to B. If there is lore than one item in the 
data base which latches a retrieval pattern, then an arbitrary 
choice is made. The fact that a choice was made is remembered 
so that if a simple failure backtracks to the decision, 
another choice can be made. 

IHVOCATIOH: Procedures can be invoked by patterns of what 
they are supposed to accomplish* Suppose that we have a 
stopped sink. One way we could try to solve the problem would 
be to know the name of a plumber whom we could call. An 
alternative which is mere analogous to pattern directed 
invocation is to advertise the fact that we have a stopped 
sink and the qualifications needed to fix it* In PLAHBEB this 
is accomplished by making the advertisement (i.e. a pattern 
which represents what is desired) into a goal. The procedure 
invoked by the pattern might or might not succeed in achieving 
the goal depending on the environment in which it was called. 
The procedure invoked can be required to undo all the actions 
that it took to try to achieve the goal. Por example if we 
were unhappy with the way in which a plumber fixed our sink, 
we could require that he restore the situation to its previous 
state. Since many theorems might match a goal, a 
recommendation is allowed as to which of the candidate 
theorems might be useful. The recommendation is a pattern 
which a candidate theorem must match. 

One basic idea behind PLAHBEB is to exploit the duality that 
we find between certain imperative and declarative sentences. 
Consider the statement {implies A B} . The statement is a perfectly 
good declarative. In addition, it can also have certain imperative 
uses for PIABHBB. It can say that we might set up a procedure which 
will note whether A is ever asserted and if so to consider the wisdom 
of asserting B in turn. [Botes it is not always wise! Suppose we 
assert < integer 0> and (implies <integer n> <integer {+ n 1)>}]» 
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Furthermore it permits us to set up a procedure that will watch to see 
if it is ever our goal to try to deduce B and if so whether A should 
be made a subgoal. Exactly the same observations can be made about 
the contrapositive of the statement {implies A B} which is (implies 
{not B} {not A}}. Statements with universal quantifiers, 
conjunctions, disjunctions, etc. can also have both declarative and 
imperative uses. PLANHEB theorems are used as imperatives when 
executed and as declaratives when used as data. The imperative 
analogues have the advantage that they can more easily express any 
procedural knowledge that we might have such as *Don f t use this 
theorem twice*. 

Our work on PLANHEB has been an investigation in PBOCEDOBAL 
f\ EPISTEflOLOGY, the study of how knowledge can be embedded in 

procedures. the THESIS OF PBOCEDUHAi BHBBDDIHG is that intellectual 
structures should be analyzed through their PBOCEDOBAL AIALOGOES. He 
will try to show what «e mean through examples: 

DESCBIPTIGMS are procedures which recognize how well some 
candidate fits the description. 

PATTEBMS ?te descriptions which match configurations of data* 
For example <either <* <atomic» is a procedure which will 
recognize something which is either 4 or is atomic. 

DATA TYPES are, patterns used in declarations of the allowable 
range and domain of procedures and identifiers. Hore 
generally, data types have analogues In the form of procedures 
which create, destroy, recognize, and transform data. 

GBAHHABS: The PBOGBAHHAB language of Terry Hinograd another 
step towards one kind of procedural analogue for natural 
language grammar. 
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SCHEHATIC DB&8IHGS have as their procedural analogue methods 
for recognizing when particular figures fit within the 
schemata. 

PROOFS correspond to plans for recogni2ing and expanding valid 
chains of deductions. Indeed many proofs can fruitfully be 
considered to define procedures which are proved to have 
certain properties. For example a proof by mathematical 
induction of a effective formula p[n] can Se considered to be 
a proof that the following function always returns "TRUE": 

p[n] :« if p[01 then MRUE" else p[n-1 ] 

Conversely § proofs by execution induction cf properties of 
procedures can be used to demonstrate mathematical facts. For 
example proofs by execution induction can imitate proofs by 
mathematical induction: 

<f n> :~ <repeat out Ux Q]] . 

* ; "initialize i to C" 

Intent: p[i] 
<cond 

[<is? .i .n> 

;*i£ .i is equal to .n then 
exit with the value 

.n« 

<.out .n>]> 
<_ :i <♦ .i 1» 
; w else increment i ard repeat fi > 

Proving the intention p[i] by execution induction will # 
establish that for all a we have p[n]. Proofs by execntion 
induction enable global properties (such as convergence and 
equivalence) to be proved by purely local analysis. 

HODELS are collections of procedures for simulating th«* 
behavior of the system being modeled. HODELS of PROGRAMS are 
procedures for defining properties of procedures and 
attempting to verify the properties so defined* Models of 
programs can be defined by procedures which state the 
relations that must hold as control passes through the 
program. 

PLANS are general, goal oriented procedures for attempting to 
carry out some task. 

THEOREBS of the QUAHf IFICATIOHAL CALCULUS have as their m 
analogues procedures for carrying out the deductions which are 
justified by the theorems. For example, consider a theorem of 
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the fora {IMPLIES x y} . One procedural analogue of the 
theorei is to consider whether x should be made a subgoal in 
order to try to prove something of the fori y. 

DRAWINGS: The procedural analogue of a drawinq is a procedure 
for Baking the drawing. Bather sophisticated display 
processors have been constructed for making drawings on 
cathode ray tubes. 

BECOMHENDATICNS: PLANHEB has primitives which allow 

recommendations as to how disparate sections of goal oriented 

language should be linked together in order to accomplish some 
particular task. 

GCAL TBEES are represented by a snapshot of the instantaneous 
configuration of problea solving processes. 

One corollary of the thesis of procedural embedding is that 
learning entails the learning of the procedures in which the knowledge 
to be learned is embedded. Another aspect of the thesis of procedural 
embedding is that the process of going from general gcal oriented 
language which is capable of accomplishing seme task to a special 
purpose, efficient, algorithms especially designed for the task should 
itself be mechanized. By expressing the properties of the special 
purpose algorithm in terms of their procedural analogues, we can use 
the analogues to establish that the special purpose routine does in 
fact do what it is intended. 

From the above observations, we have constructed a formalism 
that permits both the imperative and declarative aspects of statements 
to be easily manipulated. PtAHMEH uses a pattern-directed information 
retrieval system. The data base is interrogated by specifying a 
pattern of what is to be retrieved. Instead of having to explicitly 
name procedures which are to be called, they can be invoked implicitly 
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by a pattern (this important concept is called PATTERN-DIBECTED 
INVOCATION). When a statement is asserted, recommendations determine 
what conclusions will be drawn from the assertion. Procedures can 
make recommendations as to which theorems should be used in trying to 
draw conclusions from an assertion, and they can recommend the order 
in which the theorems should be applied. Goals can be created and 
automatically dismissed when they are satisfied. Objects can be found 
from schematic or partial descriptions. Provision is made for the 
fact that statements that were once true in a model may no longer be 
true at some later time and that consequences must be drawn from the 
fact that the state of the model has changed. Assertions and goals 
created within a procedure can be dynamically protected against 
interference from other procedures. unlike some other formalisms such 
as GPS, PLANNEB has no explicit goal tree. Instead the computation 
itself can be thought to be investigating some conceptual problem 
space. primitives for a multiprocess backtrack control structure 
give flexibility to the ways in which the conceptual problem space can 
be investigated. Procedures written in the formalism are extendable 
in that they can make use of new knowledge whether it be primarily 
declarative or imperative in nature. Hypotheses can be established and 
later discharged. PLANNER has been used to write a block coatrol 
language in which we specify how blocks can be moved around by a 
robot. Ne would like to write a structure building formalism in 
which we could provide descriptions of structures (such as houses and 
bridges) and let PLANBEB figure out how to build them. The logical 
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deductive system used by PLANNER is subordinate to the hierarchical 
control structure of the language. PLANNER theoreis operate within a 
context consisting of return addresses, goals, assertions, bindings, 
and local changes of state that hare been made to the global data 
base. Through the use of this context *e can guide the computation 
and avoid doing basically the sane work over and over again. For 
example, once we determine that ve are working within a group (in the 
mathematical sense) we can restrict our attention to theorems for 
working on groups since we have direct control over what theorems will 
be used. PLANNER has a sophisticated deductive system in order to 
give us greater power over the direction of the computation. Of 
course procedures written in PLANNER are not intrinsically efficient. 
/ *« N A great deal of thought and effort must be put into inciting efficient 
procedures. PLANNEB does provide some basic mechanisms and 
primitives in which to express problem solving procedures. The 
control structure can still be used when we limit ourselves to using 
resolution as the sole rule of inference. A uniform proof procedure 
gives very little control over how or when a theorea is used, the 
problem is one of the level of the interpreter that is used. I 
digital computer by itself will only interpret the hardware 
instructions of the machine. A higher level inter peter such as tISP 
will interpret assignments and recursive function calls* At a still 
higher level an interpreter such as HA1CHLBSS will interpret patterns 
for constructing and decomposing structured data. PLAINER cam 
interpret assertions, find statements, and goals. It goes without 
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saying that code can be compiled for any of the higher level 
interpeters so that it actually runs under a loner level interpreter. 
In general higher level interpreters have greater choice in the 
actions that they can take since instructions are phrased more in 
terms of goals to be achieved rather than in terms of explicit 
elementary actions. The problem that we face is to raise the level of 
the interpreter while at the same time keeping the actions taken by it 
under control* Due to its extreme hierarchical control and its 
ability to make use cf new imperative as well as declarative 
knowledge, it is feasible to carry out very long chains of inference 
in PLANNEB without extreme inefficiency. 

We are concerned as to how a theorem prover can unify 
structural problem solving methods with domain dependent algorithms 
and data into a coherent problem solving process. By structural 
methods we mean those that are concerned with the formal structure of 
the argument rather than with the semantics of its domain dependent 
content. 

An example of a structural method is the "consequences of the 
consequent" heuristic. By the CONSEQUENCES CF THE CCSSEQUE8T 
heuristic, we mean that a problem solver should lock at the 
consequences of the goal that is being attempted in order to get an 
idea of some of the statements that could be useful in establishing or 
rejecting the goal. 

He need to discover more powerful structural methods. PLANNER 
is intended to provide a computational basis for expressing structural 
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methods. One of the nest important ideas in PLANNEB is that it brings 
some of the structural methods of problem solving out into the open 
where they can be analyzed and gecerali2ed. There are a few basic 
patterns of looping and recursion that are in constant use among 
programmers. Examples are recursion en binary trees as in LISP and 
the FIND statement of PLANNER. The primitive FIND will construct a 
list of the objects with certain properties. For example we can find 
five things which are on something which is green by evaluating 

<FIND 5 X 

<GOAI [ON x yj> 
<GOAL [GREEN y ]» 

which reads "find 5 x's such that x is ON y and y is GREEN. 

The patterns cf looping and recursion represent common 
structural methods used in programs. They specify hew cemmands can be 
repeated iteratively and recursively. Cne of the aain problems in 
getting computers to write programs is how to use these structural 
patterns Kith the particular domain dependent commands that are 
available. It is difficult to decide which if any of the basic 
patterns is appropriate in any given problem. The problem of 
synthesi2ing programs out of canned loops is formally identical to the 
problem of finding proofs using mathematical induction. He have 
approached the problem cf constructing procedures out of goal oriented 
language from two directions. The first is to use canned loops (such 
as t le FIND statement) where we assume a-priori the kind of control 
structure that is needed. The second approach is to try to abstract 
^^ the procedure froa protocols of its action in particular cases. 
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Another structural method is PHOGBESSIVE BEFIHEHEHT. The way 
problems are solved by progressive refinement is by repeated 
evaluation. Instead of trying to do a complete investigation of the 
problem space all at once, repeated refinements are made. For example 
in a game like chess the same part of the game tree might be looked at 
several times. Each time certain paths are more deeply explored in 
the light of what other investigations have revealed to be the key 
features of the position. Problems in design seem to be particularly 
suitable for the use of progressive refinement since proposed designs 
are often amenable to successive refinement. The way in which 
progressive refinement typically is done in PLAHHEE is by repeated 
evaluation. Thus the expression which is evaluated to solve the 
^x problem will itself produce as its value an expression to be 
evaluated. 

The task of artificial intelligence is to program inanimate 
machines to perform tasks that reguire intelligence. Over the past 
decade several different approaches toward A. I. have developed. 
Although very pure forms of these approaches will seldom be met in 
practice, we find that it is useful for purposes of discussion to 
consider these conceptual extremes. One approach (called results mode 
by S. Pa pert) has been to choose some specific intellectual task that 
humans can perform with facility and write a program to perform it. 
Several very fine programs have been written following this approach. 
One of the first was the Logic Theorist which attempted to prove 
theorems in the prepositional calculus using the deductive system 
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developed in Principia Mathematical The importance of the Logic 
Theorist is that it developed a body of techniques which when cleaned 
up and generalized have proved to be fundamental tc furthering our 
understanding of A. I. The results mode approach offers the 
potentiality of maximum efficiency in solving particular classes of 
problems. On the other hand, there have been a number of programs 
written from the results mode approach which have not advanced our 
understanding although the programs achieved slightly better results 
than had been achieved before* These programs have been large, 
clumsy, brute force pieces of machinery. There is a clear danger that 
the results mode approach can degenerate into trying to achieve A. I. 
via the "hairy kludge a month plan"* The problems with "hairy 
^»*v kludges" are well known, it is impossible to get such programs to 

communicate with each other in a natural amd intimate way. They are 
difficult to understand, extend, and modify because of the ad hoc way 
in which they are constructed. 

Another approach to A. I. that has been prominent in the last 
decade is that of the uniform proof procedure. Proponents of the 
approach write programs which accept declarative descriptions of 
combinatorial problems and then attempt to solve them. In its most 
pure form the approach does not permit the machine to be given any 
information as to how it might solve its problems. The character 
table approach to A. I. is a modification of the uniform procedure 
approach in which the program is also given a finite state table of 
connections between goals and methods. The uniform procedure approach 
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offers a great deal of elegance and a laximum of a certain kind of 
generality • Current programs that implement the uniform procedure 
approach suffer from extreme ineff iciency* He believe that the 
inefficiency is intrinsic in the approach* 

FIAHBEB is not neccessarily general in the sane sense that a 
unifora proof procedure is general* PLASHES is intended to be a 
natural computational basis for methods of solving problems in a 
domain. A coaplete proof procedure for a guantif icational calculus 
is general in the sense that if one can force the nroblep into the 
fora of the input language and is prepared to wait eons if necessary, 
then the coaputer is guaranteed to find a solution if there is one. 
The approach taken in PLANHEB is to subordinate the deductive system 
to an elaborate hierarchical control structure* Although P1AHKEB 
itself is domain independent, procedures written in it have differing 
overlapping degrees of doaain independence* Proponents of the unifora 
procedure approach are apt to say that PLAHHEB "cheats* because 
through the use of its hierarchical control structure, it is possible 
to tell the prograa how to try to solve ±%s probleas* In order to 
prevent this kind of *cheating", they would restrict the input to 
consist entirely of declaratives* But surely, it is to the credit of 
a prograa that it is able to accept new iaperative inroraation and 
aake use of it* A problem solver needs a high level language for 
expressing problem solving aethods even if the language is only used 
by the problem solver to express its problem solving methods to 
itself* PLASNER serves both as the language in which probleas are 
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posed to the problea solver and the language in which aethods of 

solution are foraulated. PLANNER is not intended to be a solution to 
the problea of finding general methods for reducing the combinatorial 
search involved to test whether a given proposition is valid or not* 
It is intended to be a general foraalisa in which knowledge of a 
doaain can be coabined and integrated. Realistic problea solving 
programs will need vast aaounts of knowledge* le consider all aethods 
of solving prcbleas to be legitiaate. If a prograa should happen to 
already know the answer to the problea that it is asked to solve, then 
it is perfectly reasonable for the prcblea to be solved by table look- 
up. He should use the criterion that the problea solving power of a 
prograa should increase auch faster than in direct proportion to the 
/"■"N nuaber of things that it is told. The iaportant factors in judging a 
prograa are its power, elegance, generality, and efficiency* 
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3. Discursive Overview 



This chapter contains an explanation of scie of the ideas in 
PLANNER in essay for*. It is partially based on a draft written by T. 
Winograd for the course 6.545. If the reader would like to see a lore 
systematic presentation, he can consult the subsequent chapters. 

The easiest way to understand PLANNEB is to watch how it 
works, so in this section we will present a few siiple examples and 
explain the use of soie of its most elementary features, these 
examples are not intended to represent TOY PBOBLEHS to serve as test 
cases for "general problem solvers". The toy problem paradigm is 
misleading because toy problems can be solved without any real 
knowledge of the domain in which the toy problem is posed. Indeed, it 
seems gauche to use any thing as powerful as real knowledge on such 
simple problems. In contrast we believe that real world problems 
require vast amounts of procedural knowledge for their solution. We 
see it as part of our task to provide the intellectual capabilities 
needed for effective problem solving. He would like to see the toy 
problem paradigm replaced with an INTELLECTUAL CAPABILITY paradigm 
where the object is to illustrate the intellectual capabilities needed 
so that knowledge can be effectively embedded in procedures. 

First we will take the most venerable of traditional 
deductions: 
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Turing is a human 
All humans are fallible 
so 

Turing is fallible. 

It is easy enough to see ho* this could be expressed in the 

usual logical notation and handled bj a uniform proof procedure. 
Instead, let us express it in one possible way to PLANNEB by saying: 

<ASSEBT [HOHAN TURING]> 

<ASSEBT <DEFINE THE0BEM1 

CONSEQUENT [Y] [FALLIBLE ?Y ] 

<GCAL [HUMAN ?Y]>»> 
Function calls are enclosed between n < n and *>". the proof 
would be generated by asking PLANNEB to evaluate the expression: 

<GCAL [FAILIBLE TUBING]> 

The example illustrates several points about PLANNEB* First, 
there are at least two different kinds of information stored in the 
data base: declaratives and imperatives. Notice that for complex 
sentences containing quantifiers or logical connectives we have a 
choice wtether to express the sentence by declaratives or by 
imperatives. 

Second, one of the most important points about PLANNEB is that 
it is ar evaluator for statements. It accepts input in the form of 
expressions written in the PLANNEB language and evaluates them, 
producing a value and side effects. ASSEBT is a function which, when 
evaluated, stores its argument in the data base of assertions. In 
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this exanple we have defined a theorea of the CONSEQUENT type [we will 
see other types later]. This states that if we over want to establish 
a goal of the fora [FALLIBLE ??]# we can do this by accoaplishing tha 
goal [HUHAN ?Y ], where I is an identifier. The strange prefix 
character n l n is part of PLANNEB's pattern Batching capabilities 
[which are extensive and aake use of the pattern-Batching language 
HATCHIESS which is explained in chapter 4 of the dissertation]. If we 
ask PLANNER to prove a goal of the fora [A I], there is no obvious way 
of knowing whether A and 7 are constants [like TUBING and HUflAN in the 
exaaple] or identifiers. LISP solves this problea by using the 
function QUOTE to indicate constants. In pattern matching this is 
inconvenient and Bakes «ost patterns auch bulkier and aore difficult 
to read. Instead, PLANNEfi uses the opposite convention — a constant 
is represented by the atoa itself, while an identifier aust be 
indicated by adding an appropriate prefix. This prefix differs 
according to the exact use of the identifier in the pattern, but for 
the tiae being let us just accept *?" as a prefix indicating an 
identifier. The definition of the theorea indicates that it has one 
identifier, Y by the [I] following CONSEQUENT. 

The third statement illustrates the function GCAL, which 
tries to prove an assertion. This can function in several ways. If 
we had asked PLANNER tc evaluate <GOAL [HUflAN TUBING ]> it would have 
found the requested assertion iaaediately in the data base and 
succeeded [returning as its value soae indicator that it had 
succeeded j* However, [FALLIBLE TUBING ] has not been asserted, so ve 
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must resort to theorems to prove it. Later we vill see that a GOAL 
statement can give PLANHEB various kinds of advice on which theorems 
are applicable to the goal and should he tried. For the moment, take 
the default case, in which the evaluator tries all theorems whose 
consequent is of a for a which matches the goal [i.e. a theorem with a 
consequent [ ?Z TUBING] would be tried, but one of the fcra [HAPPY ?Z ] 
or [FALLIBLE ?Y ?Z ] would not]. Assertions can have an arbitrary list 
structure for their format — • they are not limited to two -member lists 
or three-member lists as in these examples. The theorem we have just 
defined would be found, and in trying it, the aatch of the consequence 
to the goal would cause tlie identifier I to be bound to the constant 
TDBIBG. Therefore, the theorem sets up a new goal [HOHAH TOBIHG] and 
^v. this succeeds iaaediately since it is in the data base. In general, 
the success of a theorem will depend on evaluating a PLABHEE prograa 
of arbitrary complexity. In this case it contains only a single GOAL 
statement, so its success causes the entire theorem to succeed, and 
the goal [FALLIBLE TOBIHG] is proved. The following is the protocol 
of the evaluation: 

<G0AL [FALLIBLE TOBIHG ]> [FALLIBLE TOBIHG] is not in the data base 
so attempt to invoke a theorem to esablish the goal 

enter THE0BEM1 

7 becomes TOBIHG 

<G0AL [HOHAH TOBIHG ]> is satisfied since the goal is in the 

data base 
return [FALLIBLE TOBIHG] 

The way in which identifiers are bound by matching is ot key 
importance to FLAHHBB. Consider the question "Is anything fallible?*, 
or in logic [EXISTS X [FALLIBLE X]]. This could be expressed in 
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PLANNER as: 

<PROG [X] <GOAL [IALLIBIE ?X]» 

Notice that PBGC [ PLANNEB 1 s equivalent of a LISP PBOG] in this 

case acts as an existential quantifier* It provides a binding-place 

for the identifier X, tut does not initialize it — it leaves it in a 

state particularly marked as unassigned. To answer the guesticn, we 

ask PLANNEB to evaluate the entire PBOG expression above* To do this 

it starts by evaluating the GOAL expression. This searches the data 

base for an assertion of the form [FALLIBLE ?X ] and fails. It then 

looks for a theorem with a consequent of that form, and finds the 

theorem we defined above. Now when the theorem is called, the 

identifier Y in the theorem is linked to the identifier X in the goal, 

but since X has no value yet f Y does net receive a value. The theorem 

then sets up the goal [HUMAN ?Y] with Y as an identifier. The PLANNEB 

primitive GOAL uses the data-base retrieval mechanism tc look for any 

assertion which matches that pattern [i.e. an instantiation], and 

finds the assertion [HUMAN TURING]. This causes Y [and therefore X] 

to be bound to the constant TUBING, and the theorem succeeds, 

completing the proof and returning the value [FALLIBLE TUBING]. 

There seems to be something missing. So far, the data base 

has contained only the relevant objects, and therefore PLANNEB has 

found the right assertions immediately. Consider the problem ve would 

get if we added new information by evaluating the statements: 

<ASSEBT [HUHAN SOCBATES]> 
<ASSEBT [GBEEK S0CBA1IS]> 
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Our data base new contains the assertions: 

"HUMAN TUBING 1 
"HUHA8 SOCBATES] 

i GREEK SOCRATES] 



and theorenl 
<COR 



SEQUENT ril [FALLIBLE ?I ] 
<GOAl fHbaiN ?¥]» J 



What if we new ask, "Is there a fallible Greek?" In PLANNER we 
would do this by evaluating the expression: 

<PBOG [X] 

<GOAI £FALLIELE ?X]> 
<GOAI £ GREEK ?X]» 

If PLANNER runs into a failure trying to evaluate an expression, then 
it backtracks to the last decision that was Made and dunps the 
^ responsibility of hew to proceed on the procedure which made the 

decision. Notice what night happen. The first GOAL nay be satisfied 
by exactly the sate deduction as before, since we have not reaoved 
information. If the data-base retriever happens to run into TUBING 
before it finds SOCBATES, the goal £ HUHAN ?Y ] will succeed, binding Y 
and thus X to TURING. After £ FALLIBLE ?X] succeeds, the PROG will 
then establish the new goal £GREEK TUBING], which is doooed to fail 
since it has not been asserted, and there are no applicable theoreis. 
If we think in LISP teras, this is a serious problem, since the 
evaluation of the first GOAL has been completed before the second one 
is called, and the "stack" now contains only the return address for 
PBOG and the identifier X. If we try to go back to the beginning and 
start over, it will again find TURING and so on, ad infinitum. 



3. page 43 

One of the nest important features of the PLAHHEB language is 
that backtracking in case of failure is always possible, and aoreover 
this backtracking can go to the last place where a decision of any 
sort was aade. Here, the decision was to pick a particular assertion 
froa the data base to natch a goal. Another kind of decision is the 
choice of a theorem to try to achieve a goal* PLAHBEB keeps enough 
information to change any decision and send evaluation back down a new 

path. 

In our exaaple the decision was aade inside the theorem for 
FALLIBLE, when the goal [ HOMAH ?Y] was Batched to the assertion [H0HAM 
TOEING]. PLAHHEB will retrace its steps, try to find a different 
assertion which matches the goal, find [HUHAH SOCBATES], and continue 
with the proof. The theorem will succeed with the value [FALLIBLE 
SOCBATES], and the PBOG will proceed to the next expression, <60AL 
[GBEEK ?X]>. Since X has been bound to SOCBATES, this will set up the 
goal [GBEEK SOCBATES] which will succeed immediately by finding the 
corresponding assertion in the data base. Since there are no more 
expressions in the PBOG, it will succeed, returning as its value the 
value of the last expression, [GBEEK SOCBATES]. The whole course of 
the deduction process depends on the failure aechanisa for 
backtracking and trying things over [this is actually the process of 
trying different branches down the conceptual goal tree.] This then is 
the PLAHBEB executive which establishes and manipulates subgoals in 
looking for a proof. 

■e would now like to give a somewhat more formal description 
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of the behavior of PLAKHEB 05 the above problea. If ve intoduce 
suitable notation our problea solving protocols can be aade auch aore 
succinct ana their structure aade visible. Also by formalizing the 
notions, we can aake PLAHHEB construct and analyze protocols. This 
provides one kind of tool by which PLANSEB can understand its own 
behavior and aake generalizations on how to proceed. 
In this case the protocol is; 

1: enter PROG 

2: X is rebound but not initialized 

3: <GOAL [FALLIBLE ?X]> will atteapt a pattern directed 
invocation since nothing in the data base Batches [FALLIBLE ?X1. 
4: enter TBE0BEH1 

5: aatch [FALLIBLE ?Y] with [FALLIBLE ?X ] thus linking I to X 
the situation is shown in snapshot nuaber 1 

6: <GOAL [HOHAH ?!]> finds [BDHAH TDBIBG] in the data 
base 

7: I gets the value TOBING thus giving X the value 
f~\ TDBIHG 

8: return [HOBAH TUBING] 
9: TBECBEH1 returns [FALLIBLE TDBIHG] 
10: <GOAL [GBEEK TOEING ]> fails since it is not ia the data base 
and there are no Batching consequents 

Thus PLANS EB aust backtrack to step 7 and try again. The situation is 
shown in snapshot nuaber 2. For the convenience of the reader, we 
will repeat the first six steps froa above and then continue the 
protocol. 

1s enter PBOG 

2: X is rebound but not initialized 
3: <G0AL [FALLIBLE ?X]> 
4: enter TBBOBBB1 

5: aatch [FALLIBLE ?I ] with [FALLIBLE ?X ] thus linking I to X 
6*: <GQAL [HOflAB ?T]> finds [BOBAB SOCBATIS J in the data 
base 

11: T gets the value SOCBATES thus giving X the value 
SOCBATIS 
12: return [FALLIBLE SOCBATES J 
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13: TBE0REH1 returns [FALLIBLE SOCRATES] 
14: <GOAL [GREEK SOCRATES ]> 
15: return [GREEK SOCRATES] as the top level value 

The situation is shown in snapshot number 3. 

So far vie have seen that although PLANNER is written as an 
evaluator, it differs in several critical ways froa anything which is 
normally considered a programming language. First, it is goal- 
directed. Theorems can be thought of as subroutines, but they can be 
called by specifying the goal which is to be satisfied. This is like 
having the abilitiy to say "Call a subroutine which will achieve the 
desired result at this point." Second, the evaluator has the 
mechanism of success and failure to handle the exploration of the 
conceptual goal tree. In PL AH NEB there is no explicit goal tree. The 
fs^ conceptual goal tree is represented by a SNAPSHOT of a CONFIGURATION 
of PBOCESSES. Thus PLANNER has powerful control structure primitives 
to allow the conceptional goal structure to be easily and naturally 
reflected in the execution of PLANNEB processes, ether evaluators, 
such as LISP, with a basic recursive evaluator have no way to do this. 
One of our current areas of research is to increase the richness of 
the machinery provided by PLAHNEB to guide the movement to the goal. 
Third, PLAHNEB contains a large set of primitive commands for matching 
patterns and manipulating a data base, and for handling that data base 
efficiently. 

On the other side, we can ask how it differs from other 
theorem pro vers, what is gained by writing theorems in the form of 
programs, and giving them power to call other programs wnich 
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manipulate data? The key is in the fori of the data the theorem- 
prober can accept. Host systems take declarative information, as in 
predicate calculus. This is in the for* of expressions which 
represent "facts" about the world. These are manipulated by the 
theorem- prober according to some fixed uniform process set by the 
system. PLAUHIB can make use of imperative information, telling it 
how to go about proving a subgoal, or to make use of an assertion. 
This produces what is called HIEHABCBICAL control structure. That is, 
any theorem can indicate what the theorem prover is supposed to do as 
it continues the proof. It has the full power to evaluate expressions 
which can depend on both the data base and the subgoal tree, and to 
use its results to control the further proof by making assertions, 
deciding what theorems are to be used, and specifying a sequence of 
steps to be followed. Ihat does this mean in practical terms? In 
what way does it make a "better" theorem prover? He will give several 
examples of areas where the approach is important. 

First, consider the basic problem of deciding what subgoals to 
try in attempting to satisfy a goal, fery often, knowledge of the 
subject matter will tell us that certain methods are very likely to 
succeed, others may be useful if certain other conditions are present, 
while others may be possibly valuable, but not likely. Ve would like 
to have the ability to use heuristic programs to determine these facts 
and direct the theorem prover accordingly. It should be able to 
direct the search for goals and solutions in the best way possible, 
and be able to bring as much intelligence as possible to bear on the 
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decision* In PLAHNEF this is done by adding to our GOAL statement a 
recommendation list which can specify that OBIT certain theorems are 
to be tried, or that certain ones are to be tried FIHST in a specified 
order. Since theorems are programs, subroutines of any type can be 
called to help make this decision before establishing a new GOAL. 
Each theorem ha$ a name [in oar definition on pag£ 1, the theorem was 
given the name THE0REH1], to facilitate referring to them explicitly. 

Another important problem is that of maintaining a data base with 
a reasonable amount of material. Consider the first example above. 
The statement that all humans are fallible, while unambiguous in a 
declarative sense is actually ambiguous in its imperative sense [i.e. 
the way it is to be used by the theorem prover]. The first way is to 
simply use it whenever we are faced with the need to prove [FALLIBLE 
?X ]. Another way might be to watch for a statement of the form 
[HOHAH ?ZJ to be asserted, and to immediately assert [FALLIBLE ?X] as 
well. There is no abstract logical difference, but the impact on the 
data base is tremendous. The more conclusions we draw when 
information is asserted, the easier proofs will be, since they will 
not have to make the additional steps to deduce these consequences 
over and over again. However since we don't have infinite speed and 
size, it is clearly folly to think of deducing and asserting 
everything possible [or even everything interesting] about the data 
when it is entered. If we were working with totally abstract 
meaningless theorems and axioms [an assumption which would not be 
incompatible with many theorem- proving schemes], this would be an 
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insoluble dilemma. But PLAHNEB is designed to work in the real world # 
where our knowledge is such sore structured than a set of axioms and 
rules of inference. He may very well, when we assert [LIKES ?X 
POETfil] want to deduce and assert [HUHAN ?X], since in deducing things 
about an object f it will very often be relevant whether that object is 
humat, and we shouldn't need to deduce it each time. On the other 
hand, it would be silly to assert [HAS-AS-PABT ?X SPLEEN ], since there 
is a horde of facts equally important and equally limited in use. 
Part of the knowledge which PLANHEB should have of a subject, then, is 
what facts are important, and «hen to draw consequences of an 
assertion. This is dene by having theorems of an antecedent type: 

<ASSEBT CDEflNE THB0HEH2 

ANTECEDENT [X Y] [LIKES ?X ?I] 
<ASSEBT [HUHAN ?X]»» 

This says that when we assert that X likes something, we 
should also assert [HUHAN ?X ]. Of course, such theorems do not have to 
be so simple. A fully general PLANHEB program can be activated by an 
ANTECEDENT theorem, doing an arbitrary [that is, the programmer 
whether he be man or machine has free choice] amount of deduction, 
assertion, etc. Knowledge of what we are doing in a particular 
problem may indicate that it is sometimes a good idea to do this kind 
of deduction, and other times not. As with the CONSEQUENT theorems, 
PLANNEB has the full capacity when something is asserted, to evaluate 
the current state of the data and proof, and specifically decide which 
ANTECEDENT theorems should be called. 

PLANNEE therefore allows deductions to use all sorts of 
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knowledge about the subject Batter which go far beyond the set of 
axioms and basic deductive rules. PLANHER itself is subject- 
independent # but its power is such that the deduction process never 
needs to operate on such a level of ignorance. The programmer can put 
in as much heuristic knowledge as he wants to about the subject, just 
as a good teacher would help a class to understand a mathematical 
theory, rather than just telling ehem the axioas and then giving 
theoreas to prove. 

Another advantage in representing knowledge in an imperative 
form is the use of a theorem prover in dealing with processes 
involving a sequence of events. Consider the case of a robot 
manipulating blocks on a table. It might have data of the form, 
f^ "blockl is on block2 # " "blcck2 is behind block3", and "if x is on y 

and you put it on z # then x is on z 9 and is no longer on y unless y is 
the same as z w . Hany examples in papers on theorem provers are of 
this form [for example the classic "monkey and bananas" problem]. The 
problem is that a declarative theorem prover cannot accept a statement 
like [OH B1 B2] at face value. It clearly is not an axiom of the 
system, since its validity will change as the process goes on* It 
usually is put in a form [OH B1 B2 SO] where SO is a symbol for an 
initial state of the world. The third statement might be expressed 
as : 

[FOB- AIL T0PB10CK HBBSOPPOBT CLDSOPPOBT S 
[AMD 

[ON TOPBLOCK HBBSOPPOBT [POT TOPBICCK HBBSOPPOBT S]] 
[OB 

[EQUAL NEWSOPPCBT OLDSUPPOIT] 
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[NOT [CN 

TOPBLCCK 

OLDSUPPOBT 

[PUT TCPBLOCE NEWSUPPOBT S]]]]]] 

In this representation, [POT XI S] is the state which results 
from putting X on Y when the previous state was S* We run into a 
problem when we try to ask [CN Z B [PUT X Y S]] i.e. is block Z on 
block W after we put X on Y? A human knows that if we haven* t touched 
Z or W we could just ask [ ON Z W S ] but in general it may take a 
complex deduction to decide whether we have actually moved them, and 
even if we haven«t, it will take a whole chain of deductions [tracing 
back through the time sequence] to prove they haven 1 t been moved* In 
PLANNEB, where we specify a process directly, this whole type of 
problem can be handled in an intuitively more satisfactory way by 
using the primitive function EBASE. 

Evaluating CEBASE [CN ?X ?Y ]> removes the assertion [ON ?X ?Y] 

from the data base. If we thick of theorem provers as working with a 

set of axioms, it seems strange to have function whose purpose is to 

erase axioms. If instead we think of the data base as the "state of 

the world" and the operation of the prover as manipulating that state, 

it allows us tc make great siaplif icaticns* Now we can simply assert 

[ON B1 B2] without any explicit mention of states. He can express the 

necessary theorem as: 

<ASSEBT <DEFIN£ THE0BEM3 

<CCNSEQUENT [TCPBLOCK NEHSUPPCBT OLDSUPPOBT] 

[POT 7T0PELOCK 7NIWSDPPOBT] 

<GOAL [ON 7T0PBL0CK 3CLDSUPPCBT ]> 

<EBASE [ON 7T0PBL0CK 7CLDSUPPOBT ]> 

<ASSEB1 [ON 7TCPBLGCK ?NEWSUrPOBT ]»» 
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This says that whenever we want to satisfy a gcal of the form 
[POT ?TOPBLOCK 7NEWSDPP0RT ], we should first find out what thing 
CLDSUPPOST the thing TCPBLOCK is sitting on # erase the fact that it is 
sitting on OLDSUPPORT, and assert that it is sitting en NEMSUPPORT. 
We could also do a number of ether things, such as proving that it is 
indeed possible to put TOPELCCK on NEHSUPPOST, or adding a list of 
specific instructions to a movement plan for an arm to actually 
execute the goal. In a more complex case, other interactions might be 
involved. For example, if we are keeping assertions of the form 
[ABOVE ?X ?Y ] we would need to delete those assertions which became 
false when we erased [CN ?X ?Z ] and add those which became true nhen 
we added [ON ?X ?T ]♦ ANTECEDENT theorems would be called by the 
^^ assertion [ON ?X ?Y] to take care of that part, and a similar group 

called ERASING theorems can be called in an exactly analogous way when 
an assertion is erased, to derive consequences of the erasure* Again 
we emphasize that which of such theorems would be called is dependent 
on the way the data base is structured, and is deter lined by knowledge 
of the subject matter* In this example, we would have to decide 
whether it was worth adding all of the ABOVE relations to the data 
base # with the resultant need to check them whenever something is 
moved, or instead to emit them and take time to deduce them frcm the 
ON relation each time they are needed. 

Thus in PLANNER, the changing state of the world can be 
mirrored in the changing state of the data base, avoiding any need to 
make explicit mention of states, with the requisite overhead of 
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deductions* This is possible since the information is given in an 
imperative fora, specifying theorems as a series of specific steps to 
be executed, fLANNSB also allows the construction of local data bases 
called states which are variants of the global data base. Evaluation 
of PLA88EB expressions is carried cut relative to a local state. Thus 
siaultaneous consideration can be given to two incompatible states of 
the world by explicitly calling the e valuator to evaluate statements 
in the two states. 

If we look back to the distinction between assertions and 
theorems made at the beginning of this chapter, it would seem that we 
have established that the base of assertions is the "current state of 
the world", while the base of theorems is our permanent knowledge of 
how to deduce things from that state. This is not exactly true, and 
one of the most exciting possibilities in PLANNER is the capability 
for the program itself to create and modify the PIANHB1 functions 
which make up the theorem base. Bather than simply making assertions, 
a particular PLANHEB function might be written to put together a new 
theorem or make changes to an existing theorem, in a way dependent on 
the data and current knowledge. It seems likely that meaningful 
"teaching" involves* this type of behavior rather than simply modifying 
parameters or adding more individual facts [assertions] to a 
declarative data base. 

For example suppose we are given the following protocols for a 
function f. An expression such as "new [5*1]" means that we are 
introducing a new identifier which is 5 * 4 * 20. 
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<f C> : 0=0 IS TBOE SO 1 
Thus <f 0> = 1 



rhich i» T ftuS b s;%s p £s^?'ij*i8:' " to coBpute <f o> *™ test °~° 



<f 1> : 1*0 IS FALSE SO 

1 * new [1-1] 0=0 IS TBUE SO 1 
Thus <f 1> = 1 



«n~i. ^ The above expression reads,, "to coapute <f 1> yoo test 1*0 
which xs false so the answer is 1 times the guantity which is computed 
by first computing the intermediate result 1-1 then testing if 0*0 
which is true so the guantity is 1." 

<f 2> : 2=0 IS FALSE SO 

2 * new [2-1] 1=0 IS FALSE SO 

1 * new [1-1] 0=0 IS TBOE SO 1 
Thus <f 2) =2*1*1=2 

<f 3> : 3=0 IS PALSE SO 

3 * new [3-1] 2=0 IS FALSE SO 

2 * new [2-1] 1=0 IS FALSE SC 
— ^ 1 * new [1-1] 0=0 IS TRUE SO 1 

f Thus <f 3> = 3 * 2 * 1 * 1 * 6 

By the process of "variabalization", we conclude that the 
above protocols are compatible with the following program which is in 
the form of a tree [which we shall call the protocol tree]. 

<f x0> = if xC=G then 1 

else xO * new [[x0-1]=x1] if x1=0 then 1 

else x1 * new [[x1-1]=x2] if x2=0 then 1 
else x2 * new [[x2-1]=x3] 
if x3=0 then 1 
else., . 

How by identifying indistinguishable nodes on the protocol tree, we 
obtain: 

<f x> = if x=0 then 1 

else x *<f [x-1]> 
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The reader will note that f is the factorial function* PLAHBEB 
procedures and theorems can be taught in precisely the sane fashion 
[which we call procedural abstraction]. For exaaple, the computer can 
be taught to build a vail or recognize a tower fro* exaaples. The 
reader is cautioned that although we shall speak of the computer being 
"taught" * we do not assuae that anything like what has been 
classically described as "learning" is taking place. le assuae that 
the teacher has a good working aodel of the student that is being 
taught and that he honestly atteapts to convey a certain body of 
knowledge to the student. Of course the student will be told anything 
which aight help hia to understand the aaterial faster* 

Procedural abstraction is one way in which a special purpose 
routine can be constructed froa general goal oriented language. Be 
would like to express the Intended properties of the special purpose 
routine so that we can establish that the routine really does what it 
is supposed to do. For exaaple we aight be interested in establishing 
that the function divide defined below satisfies its intentions* 

<define divide <f unction idivide 

;"let idivide be naae of this activation" 

[n d] 

;"the function divide is a function of two arg laents a and d" 

<repeat [[r •*] [gt 0]] 

; "initialize r to n and g to zero" 

;"we are in a repeat loop which will repeatedly 

execute the following ex pressioas" 
<cond 

[<is? <less .d> .r> 

;"if «r is less than .d then" 

<. idivide .g .r> 

;"exit the activation naaed 

idivide with -g aad .*"]> 
<assign :r <- «r .d» 
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;"assign r the value of r ainus d" 
<assiqn :g <+ .q 1» 
; "assign q the value of q plus 1" 
;"now go back and do the body of the repeat 
loop all over again">» 

We shall express the intentions of the function DIVIDE in a 
goal oriented formalism called INTENDEB. IBTEHDEB enables us to emed 
the intentions for a program in the text of the program. The easiest 
way to understand IBTEBDBR is to watch how it works. In order to 
show how it works we must first define soae intentions. IHTEHDEB 
introduces two new primitives CVEBALL and IBTEHT to express intentions 
in code. The primtive OVEBALL expresses the overall intention of a 
function or loop whereas IHTENT asserts that the intended situation 
really holds within the body of the function or loop. The meaning of 
^•^ the intentions embedded in the function DIVIDE are explained below. 
INTEHDEB is a giant sledge hammer to use to squash such a tiny 
problem. The reader can see this sledge hammer used on harder 
problems in chapter 7. IBTEHDEB needs to be able to talk about 
function calls in a pattern directed nay. He will use !• to suppress 
procedural invocations. Thus whereas <♦ 3 5> evaluates to the BOBBER 
8, the expression !•<♦ 3 5> will evaluate to the CALL <♦ 3 5>. 
Assertions which contain calls constitute a still higher level 
assertion than the two which we have introduced thus far. The 
semantics of such assertions are determined in part by the body of the 
procedure which is called. Tor example the assertion that !•<* !•<♦ 1 
2> !•<+ 2 1» can be established from the DEFIBITICH of ♦. Similarly 
in a very incestuous way, we can make assertions about PLABBEB 
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procedures whose intentions are theaselves written in P1ABHEB and at 
any given tiie constitute the model that PLANNER has of itself! By 
using intentions expressed in PIAHHEB, there is nothing that in 
principle P1ASHEB cannot be nade to understand about itself. 

<define divide <function idivide [n d] 

<overall £ } 

<intention [ ] 
<and 

<goal l*<is !»<greater 0> .n» 
<goal !«<is !»<greater 0> .d>» 

<and 

<assert !»<is !»<greater 0> .n» 
<assert !«<is !»<greater 0> .d»» 
<repeat [£r .n] [g 0]] 
!;<intention 

<goal !•<* .n !*<♦ .r !'<* •* .q»» 
<assert !•<= -n !•<♦ .r !•<* -d •g»»> 
<ccnd 

[<is? <less .d> .r> 

<. idivide .g .r>]> 
<assign sr <- .r .d» 
<assiga :g <♦ .g 1>» 
<f unction [Q B] 
<intention [ ] 
<and 

<assert !•<* .a !•<♦ .B !•<* .d .Q»» 
<assert !*<is? !*<less .d> .B>» 
<and 

<goal !••<» .a !•<♦ -B !•<* .d .Q»» 
<goal !*<is? !«<less .d> .B»»»>» 

The overall intention for the function DIVIDE is that it return two 
values Q and B whicn we assert will have the property that 

!«<=.n !•<♦ .B !•<* .d .Q>» 

The inside intent of the function DIVIDE is the goal that DIVIDE will 
return two values Q and B which will have the property that 

!»<«.» !•<♦ .B !•<• -d .Q>» 
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The body of DIVIDE is a BEPE1T loop with two locals r and g which are 
respectively initialized to and n. The overall intention of the 
EEPBAT loop is the goal 

!*<= .n !•<♦ .r !•<* .d .g>» 

The BEPEAT loop has an intent that asserts that 

!*<=.n !•<♦ .r !»<* .d .g»> 

at the top of the loop. 

The intentions for DIVIDE are proved by running then in 
INTBHDEB. The intentions are verified abstractly, thus they aust be 
true independent of what the actual arguments to the function are. He 
shall use the notation x_n for the nth value of the identifier x with 
^ x_ being an abbreviation for the initial value of x. The actions of 
IHTEHDEH on the intentions of DIVIDE are as follows: 

Fron the overall all intentiion of the function we have: 
<assert !»<is !*<greater 0> n » 
<assert !»<is i*<greater 0> d~» 

repeat loop follo *i»9 assertions coie froa the declarations of the 

< assert •<« r_ n_» 
<assert •<» q~ 0>> 

satisfied: 6 inteBtioa of ta « repeat statenent on first entry is 
<goal H<a 
n 
!•<♦ 

r_ 

!•<♦ a_ a - »» 
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r 1 

enter intentions of CCHD 

There are two cases for the ccndxtional: 

Case 1 : 
<assert !«<xs? 

!«<less d_> 

r_1» 

Prom the overall intention we have: 
Q becomes g_1 
B becocomes r 1 
<goal !•<= 
n 
!<"<♦ 

r 1 

!»<* a_ q.1»» 
<goal !*<is? !«<less d~> r_1» 

Case2: 
<assert !»<is? 

!'<greater* d_> 

r_1>> 

Proa <assign :r <- .r .d» we get: 
<assert ! * <= 

r_2 

!•<- r_1 d_>» 

Prom <assign :g <♦ .g 1» we get: 
<a«>sert !'<* 

q-2 

!•<♦ g_1 1>» 

The recursive goal is satisfied by simplification: 
<goal !•<* 
n 
! 7 <* 

r_2 

!«<* d q_2»» 
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4. THE PATTERN BATCHI86 LANGUAGE 'ATCLLESS 



HATCHLESS is a pattern directed language that is used in the 
implementation of PLANNER. HATCHLESS is used both in the internal 
workings of PLANNER and as a tool in the deductive system itself. 
HATCHLESS is similar in certain respects to ether structural pattern 
matching languages such as CONVERT and SNOBOL. it has been designed 
with the following considerations in mind: 

0. The language must obey the Fundamental Principle of Pattern 
Directed Computation: the procedure body should be a pattern that 
describes the purpose cf the procedure. The principle has been 
developed even further in PLANNER where procedures are invoked on the 
basis of their intent. 

1. The language should be very powerful yet simple constructs 
should be efficiently compiled. By incorporating more knowledge into 
a program, it Bust be possible to increase its efficiency up to the 
limits imposed by the machine on which it runs. 

2. Functions must be able to be separately compiled. 

3. It should not require parsing for efficient 
interpretation. Procedures should be naturally and efficiently 
constructed and edited by ether procedures. 

4. The language must interface with PLANNER in a natural way 
since it is used as a basic, part of the deductive system. Effective 
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problem solving requires a sophisticated programmable matcher. 

5. The language should treat strings, list*, vectors, tuples y 
and nodes symmetrically so that for the most part the same program 
nill run whether the structures are made up of vectors, tuples, nodes, 
or lists* Declaration* determine which form is actually used* 

6* The language should hare no automatic coercion. Any 
procedures which wish to coerce their arguments should be able to do 

so easily* 

7. The language should have only one mode of evaluation for 
value* Locatives should always be generated explicitly in the same 

way* 

8. Ill the loops of the language should be guaranteed to be 

properly nested* 
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4.1 The Syntax of Identifiers and Expressions 



AITCHLESS attempts to obey the Fundamental Principle of 
Pattern Directed Computation: the procedure body should be a pattern 
of what the procedure is supposed to accomplish* For example it 
allows the list (a b c) to be produced by simply evaluating (a b c) • 
In attempting to realize the principle we have been led to develop a 
certain amount of syntax which (unfortunately!) must be described* 

4*1*1 Prefix Operators for Identifiers 

As is usual in pattern matching languages we shall allow 
constants lite 3, a, (a b) , and (e (f g)) to match only themselves* 
An identifier is indicated by a prefix operator vhich tells how the 
identifier is to be used* For example .x is the element value of the 
identifier x. If x has the value (a 3) then *x will only match (a 3). 
We need to be able to change the value of an identifier in a pattern 
match* Suppose that x has the value 3* If ve match _x [the 
tentative value of x] against (a b) , then x is given the value (a b) . 
The identifier x will keep the value (a b) if the remainder of the- 
pattern matches* Otherwise the value of x will revert to 3* Again 
suppose that x has the value 3* If we match :x [the altered value of 
x] against (a b) # then x is given the value (a b). However the value 
of x will remain (a b) whether or not the remainder of the pattern 



^s 



4. 1 page 62 
matches. 

The above prefix operators are actually defines in terms of 
procedure calls. We are not enamored with the syntax of the prefix 
operators but they are easier to type than the procedures listed 
below, 

A small meta syntax is needed in order to give explanations of 
the primitives of the language. He shall use J to delimit 
metasyntatic variables which are elements and - to delimit those which 
are sequences. 

The following table explains the prefix operators which yield 
element values: 

.Jxl » <VALBE jx|> the element value of the identifier Jxj 

,]x] = <GlOBiL | x J > the element global value of ]x| 



The following table explains the prefix operators which match 
elements: 

?|x| - <GIVEH lx l > will give Jxj the value of the matching 
element if Jxj does not already have a value; otherwise ?JxJ will only 
match the value of Jxj. 

:jx| * <ALTER!-PEBSISTEHT Jx l> will alter the value of x to be 
the matching element even if Jx| already has a value. 

_Jxi * <ALTEB!-TEHT1TIVE |x |> will tentatively alter the value 
of lx J to be tie matching element but if a failure backs up then the 
old value of 1 x) will be restored. 
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If x has the value (a 1) then <b .x 4) will evaluate to (b (a 
1) 4). The character ! is the escape character* He will use !*x to 
denote the segment vaXne of the identifier x* For example (b !.i 4) 
will evaluate to {b a 1 4) • In each case preceding the prefix 
operator for an identifier will result in the segment prefix operator 
for that identifier* If ye Match the pattern (c !:x d) against the 
value (c 3 a d) then x will be given (3 a) as its value* 

The following table explains the prefix operators which yield 

segment values: 

I.Jxj « {VALUE Jxj} the segment value of the identifier |x| 
!, jxl * {GLOBAL |x|} the segment global valne of )x| 



The following table explains the prefix operators which Match 

segments: 

!?|xj * {GIVEH x) will give x the value of the matching 
segment if x does not already have a value; otherwise !?x will only 
Match the value of x. 

!:x « {ALTEBl-PEBSISTEHT x} will alter the value of x to be 
the Matching segMent even if x already has a value* 

J_lx| * {ALTEBf-TEMTATIfE ixj} will tentatively alter the 
value of I x( to be the Matching segMent but if a failure backs up then 
the old value of |xl will be restored* 

Gerry Sussman and I have developed the following scheMe for 
looking up the values of identifiers in interpreted code* On the 
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identifier stack when an identifier is bound the following information 
is stored: 

1. the name of the identifier 

2. the current value of the identifier 

3. the place on the stack where the identifier was previously 

bound 

Associated with each binding environment and identifier we have the 
place on the identifier stack where the identifier was last bound. 

4. 1.2 Syntax of Expressions 

MATCHLESS uses Polish prefix notation for function calls with 
the actual call delimited by < and >. Of course we use the characters 
( and ) to delimit lists. Me use the characters [ and ] to deliait 
vectors. For example <+ 2 3> evaluates to 5. If y has the value 4* 
then <♦ .y 1> will only match 5. The value of {.j) is (4) and the 
value of (<■♦ .j 1> (« a) .y) is (5 (4 a) 4). If the function call is 
to denote a segment then it is delimited by { and }• The function 
REST will return the rest of the list that it is given as an argument. 
For example <rest (a b c)> evaluates to (b c) . But (1 {rest (a b c) ) 
e f) evaluates to (1 b c e f ) • Furthermore, (a b {rest (1 (e t ) g) } 
k) will o«ly match (a b (e f) g k) . The components of lists, vectors, 
and nodes can be selected by subscripting. For example <2 (a b c)> 
evaluates to b and <3 [ (a) e 5]> evaluates to 5. The expression <get 
|ii |x|> mill return the location of the fifth component of the 
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structure )i). Other values are computed from patterns. The value of 
[.y (a b) .jl is £4 (a b) 4]. Tuples are stored in the stack whereas 
the vectors are garbage collected. lexically the scope of a tuple is 
the smallest enclosing pair of < and > or { and }. Otherwise vectors 
and tuples are indistinguishable. An argument of a function nay be 
computed in parallel with the other arguments by delimiting the 
argument with |< and > instead of < and >. For example 7*3 could be 
computed in parallel with 2+4 in the expression <* !<♦ 7 3> <♦ 2 4». 
An argument of a function HBST be able to be computed in parallel if 
it is delimitted by !]< and >. in other words, if one branch becomes 
blocked the otter must be able to continue execution. 
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4.2 Types 



The type hierarchy is: 

<?> for the universal type. 

<WOBD> for primitve types which are not pointers. 

PALSE for the logical type faj.se. ill other, data are 
considered to be true in conditional expressions. The null 

function call <> will evaluate to #FALSB. 

CHABACTE8 for a character such as ! w a or !*U. Again we are 
using ! as an escape character. The ! converts * into the 

guote for a single character. 

<H0HBEH> for numbers. 

<FIXED> for fixed point number. 

FIX for a small fixed point number. 

BIG for a big fixed point nuaber. 

FLCAT for floating point number. 

<POIHTEB> for pointers. 

ATOH for atoms. The following are all atoms: a, foo, and 
hello 

<STBDCTOBE> fox structured data. The operations of taking the 
BEST of a structure and selecting the nth element are defined 

on all structures including tuples, vectors, lists, and nodes. 

For some structures the operations are more efficient because 

of special hardware. 

TUELE for a tuple of elements. Tuples are allocated from 
the stack cf a process and are deleted on procedure exit. 

Tuples occupy contiguous blocks of memory. Once a tuple 

has been created its structure cannot be changed and its 

length can not be increased. 

VECTOB for a vector. Vectors are allocated contiguous 
blocks of storage which are garbage collected when no 

lortger pointed at. Although the structure of a vector 
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cannot be changed # its length can be increased at the cost 
of a garbage collection. Otherwise vectors are identical 
to tuples* 

STEIHG for a string* This is just a vector of characters* 
For example *ba w # «3 m and "a b" are strings 

LIST for a list, lists have the advantage over vectors 
that their structure can be changed after the; have been 
created. They have the disadvantage that it takes a time 
proportional to n to get the nth element* 

NODE for a node which has properties* Hodes are the most 
general form of structured data in the language* The 
others are included for reasons of efficiency for 
specialized structures* The components of a node are 
obtained by subscripting which is currently implemented by 
hash coding* A vector is approximately one third the size 
of its corresponding representation as a node* 



The following types will not be explained here. They are 

included only for completeness* The complicated types and their 
abbreviations are: 

JUMCTICH for junction 

ACTITATIOH for activation* 
STATE for state* 
ARC for a node arc* 
BIHD for bindings* 

<LOCATI¥£> for a locative or generalized location. 

VECTOB-IOCATIVE for a locative to an element of a vector. 
TO FIB-LOCATIVE for a locative to an element of a tuple* 
BIIDIIG-LOCATIVS for a loactive to the value of an identifier 
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LIST-LOCATIVE for a locative to an element of a list. 
LIST-BEST-LOCATIVE for a locative to the rest of a list. 
NODE -LOCATIVE for a locative to an eleaent of a node. 

IABEI for a label function. 

PBOCESS for process. 

STACK for a stacX 

BIHG for a ring 

ELEBENT-CAIL for a eleaent call. 

SEGMENT-CALL for a segient call. 

SEGHEHT-VALUE-CALL for a segment value call. 
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4.3 Simple Examples of Hatching 



The idea of structural matching is fundamental to the 
MATCHLESS processor, fly means of the primitive function <IS? 
| pattern | ] expression |> we can determine if J pattern] matches 
Jexpressionj . The function IS has the value true if the match 
succeeds and <> (which is FALSE) otherwise. Pattern matching takes 
place through the use of side effects to change the values of 
identifiers to be those of the objects which they match. The 
assignment statement in MATCHLESS is a variant of the primitive IS. 
The expression <_ J pattern) |expressionj> is well defined only if 
|pattern| matches (expression). The value of the function _ is the 
value of )expression| . Below we give some examples of matching where 
the values of identifiers are listed after assignment statements have 
been executed. Be use the character - to delimit segments. For 
example the list (a b c) has subsegments: 

--* -a~ # -a b- # -a b c- # -b c- 9 -b- # and ^c^. 

The characters < and > are used to delimit function calls. 

<prog [a [!=atcm h] c] 

;*This is a comment. 

He are inside a program in which we have 
declared a # declared h to be of type atom, 
and declared c" 
;*in the test below 

the function IS will return true 

since the pattern (_a k _h !_c) matches 

the value {(1) k b o a) w ~ ~ 
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<is? (_a k _h !_c) ((1) k b o a)» 

a gets the value (1) 

h gets the value b 

c gets the value (o a) 
The value of the program is true which is the value of the IS 
st ate lent. 

<prog [c L«*ftc« hi a] 

;*h is of type atoa" 

<is? {!_c _h k _a) (a j b k g) » 

c gets the value (a j) 

h gets the value b 

a gets the value g 

<prog [first last Middle J 

<is? <_first !_afddle _last) (a b c d) » 

first gets the value a 

aiddie* gets the value (b c) 

last gets the value d 

<prog [a b ] 

<is? (_a _b) |d) » falls because there is only one 

eleaent in (d) • 

/"*\ <P"9 [[l^atca a]l 

;*a xs of type atoa" 

<is? _a {o t)» fails because (o t* is net an atom. 

An expression that consists of the prefix operator "+* followed by a 
identifier will only match an object equal to the value of the 
identifier* 

<prog [a] 

<is? {!_a Ua) (a b c a b c) » 
a gets the value (a b c) 

<prog £a b] 

<is? (!_a x !.a !_b) (a b x d x a b x d g) » 

a gets the value (a b) 

a failure occurs because (I«a S w b) vill not natch (d x 

a b x d g) 

a gets the value (a b x d) 

b gets the value (g) 

An expression that consists of the prefix operator ? £the value given] 
followed by an identifier aatches the value of the identifier if it 
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has one, othemi.se the identifier is assigned a value. 

<prog [a] 

<is? ?a t» 

a gets the value t 

<prog [[I^fix [a 51]] 
* L <is? ?a 4>V J 

a is declared to be of type fix and initialized to 5 

on entrance to the prog. Consequently the assignment statement fails. 

<prog [a] 

<is? (J_a !?a) (a b c c fc a)>> fails because once a is 

assigned a value, a can only match a segment that is egual to the 
value of a. 

The function HATCH? is somewhat more powerful than the 
function IS? because it can match patterns against patterns. 

<prog [x y] 

<match ?x ?y> 

; w link x and y by matching them to each other 11 

<match ?x 3> 

;*let x have the value 3 and thus set y to 3 n 

•y 

; f, the value of y is the value of the prog M > evaluates 
to 3 

Restrictions on the value of an identifier can be acquired as 
the result of a match. 

<prog [x] 

<match ?x <less 5>> 

;"x vill only match numbers less than 5" 

<match 6 ?x>> fails since 6 is not less than 5 

Side effects can propagate through structures: 

<prog [x y 2 ] 

<match ?x [?y !?z]> 

<match (a b c) ?x> 

;«y gets the value a and z gets the value (b c) "> 
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4*4 Definitions of Procedures 



4*4*1 Functional Procedures 

<FUHCTICH 

♦checker* ♦activation-name^ [-function-declarations- ] 
-expressions- > where ♦activation- name* and ♦checker* are optional, 
will evaluate to a function which will, when it is called, bind the 
formal parameters in the |f unction-declarationsi to the actual 
parameters, evaluate the -expressions- returning the value of the last 
one as the value of the function. The ♦checker* must be of the form 
/""*% <|procedure| -arguients-> for one value or {I procedure} -arguments-} 
for multiple values* The ♦checkers is treated as a pattern that the 
values returned must match. The match is done so that any side 
effects are persistent. The (-function-declarations-] is of one of 
the following forms: 



larguments-specificationj which may be one of the following: 
[-formal-paraaeter-specifications- ] where each formal- 
parameter-specification is of one of the following forms: 

|evaluaticn-specification| where each jevaluation- 
specif icationl must be one of the following: 

M identifier I means that the (identifier) is to be 

bound to the write protected UNEVALOATEE corresponding 

actual parameter. 

i identifier! means that the (identifier} is to be 
ound to the VAiOE of the corresponding actual 

parameter 
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( | attribute-specification | ]evaluation-specif ication] ] 
where the Jattribute-specif icationj must be one of the 

following: 

|attribute| 

[•attributes- ] 

where each attribute nust be one of the following: 
-*"SP£CIiI»* aeans that the identifier maj be Ssea 

free in other aodules* The symbol -t"SPECIAi" is a 

unique string* 

< I procedure | -argunents-> aeans that tke 
identifier nust always be either unassigned or 

bound to an object which matches the pattern 

< | procedure | -arguaents->. The constraint is 

enforced by PLANHES* Any side effects of Batching 

the pattern against the new value of an identifier 

are persistent* 

-forsal-paraaeter-specifications- -i*0P3IQHtL* -optional- 
oraal- paraaeter- specifications- ] 

where an |optional-f oraal-paraaeter-specif icatio*} is 
either a |f or mal- parameter-specification] or [ lat tribute- 
specification | [ (evaluation-specification I 1 initial- 
value | ]]. The ^•OPTIOHIl* construct is due to Chris 
Reeve. It alows for optional arguaents and specifies how 
the identifier is to be initialized if the actual 
paraaater is not present* 

[-formal- paraaeter- specifications — •"BEST" J identifier- 
specification]] which will bind the identifier in {identifier- 
specification] to the tuple of the rest of the arguaents 
evaluated* 

[-fornal-paraaeter-specifications- -"•"BEST" • ] identif ier- 
specif icationj ] which will bind the identifier in lideatifier- 
specif ication | to the write protected vector of tne rest of 
the unevaluated arguaents* The f variant is due to Garv 
Pes kin. 



[ **"BIHD" | identifier-specification] 1 argument s-specif cation | - 
declarations-] is used to first bind the identifier in 
I identifier-specification] to tlie bindings in effect when tke 
function is invoked* In alaost all cases use of -*"BIW1>* can 
be avoided by reading the function into a local syntactic 
block so that no identifier conflicts can occur* 
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/*> 

[-*"P*TTE1H" J calling- pattern J J arguaents-specif cation 1 ] 
defines a calling pattern for pattern directed invocations. 
The calling pattern is of the fora [-declarations- J pattern | ] 
which declares identifiers for J pattern). 

For example; 

«function [-."rest" x] <2 .x» 11 21 33> evaluates to 21 
since <2 [11 21 33 ]> is 21 

«f unction [-."rest" 'x] .x> 

<♦ 3 4> 

c> evaluates to [a <♦ 3 1> c] 

«f unction [x] .x> 3> evaluates to 3 

«function [x] .x> a> evaluates to a 

«f unction !=fix [[!«fix x]1 .x> <♦ 2 2» evaluates to « where 
!=fix is <CF-TxPE fix> 

«f unction !*fix [[!»fix x]] <♦ .x 1» 2> evaluates to 3 

«function !«fix [[ !=fix x] [ !=f ix y 33 <♦ .x .y» 2 3> 
evaluates to 5 

« function [x -•" optional" [y 3]] <♦ .x .y» 4> evaluates to 7 
«f unction [x -."optional" [y 3]] <♦ .x .y» *» 5> evaluates to 

«function [[!*fix »x]] .x> 3> evaluates to 3 
«f unction [*x] .x> a> evaluates to a 
« function [«x] .x> <♦ 2 2» evaluates to <♦ 2 2> 
Be would like to give a sinple exaaple of pattern directed 
invocation. Suppose that we have a sink s which we need unstopped. 
The classical solution is tc know the naae of a plunber which could be 
applied to the sink. Thus for exaaple we night evaluate <pluuber- 
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Perl nan s>. The nay we shall actually proceed is to advertise that we 
need a sink unstopped. Of ccuse we won't let just anyone work on our 
sink; he oust coae well recommended. For example he should be cheap 
and speedy. He will evaluate 



<call 

£<[ unstop s] $5> 

<speedy> ]> 
to offer to let some oie unstop our sink for $5 provinding he is 
speedy. How suppose that there are a few plumbers around: 

<define plumber-Greenilatt 
<function 

[-^pattern* 1 

[[sink] [unstop ?sinkl] 
fee] 
<cond 

[<is <less $4> .fee> 
<fail>]> 
;" if the fee is less than $4 

then fail" 
<Roto- Hooter .si**k> 
; "otherwise apply Boto-Rcoter 
to the sink*» 

<define plumber- Perlman 
<f unction 

[^"pattern" 

[[sink] [unstop ?sink]] 
fee] 
<pour Drano .sink> 
;"pour Drano in the sink" 
<send-bill <times 2 .fee» 
;"send a bill for twice the originally 
agreed fee"» 

To try to get our sick unstopped we might evaluate: 

<prog [ ] 

<call 

[<[ unstop s] $5> 
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<speedy> ]> 
; "advertise for a speedy plumber to 

unstop sink s for $5" 
<ccnd 

[ <stopped-up? s> 

<f ail> ]> 
;"if the sink is still stopped up 

then try again n > 

Suppose that both plumber-Greenblatt and plumber-Perlman are 
classified as speedy. Thus PI&MHEB will chose one or the other to 
invoke since both have patterns which natch the calling pattern 
[unstop s]. If either one fails then the other will be tried. If one 
returns but the sink is still unstopped when he gets back then the 
mess the first created will be undone and the other tried. 

Be can define the function reverse which returns a newly 
constructed reverse of its argument as follows: 

<define reverse <f unction [x] 
<rule [ ] . x 
|[ <eopty> 

.x] 

[<structure> 

«storage .x> {reverse <rest .x>} <1 .x»J 
^"else" 

<error>>» 

Thus <reverse [a [b c] 4]> is [4 [b c] a]. 

Functions with an arhitrary number of arguments are 
accommodated by passing a tuple which contains the evaluated 
arguments. Suppose that we already have a function PLCS which will 
add two numbers together. 
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<define ♦ <fu fiction pi 

;"let the name of the current activation be pi* 

[-•"rest" x] 

;"we will receive a variable number of 

arguments in the tuple x" 
<for 

[[result 0] n] 

;" initialize the identifier result to 0" 
[[-."test" 

<is? [ ] «x> 
<.pl .result> 
;"exit .pi with .result" 
; H each time before executing 
the loop test to see 
if x is a null tuple and if so then 
return the result"] 
[-•"step" <chop x>] 

;" after each pass through the loop chop x by 
assigning x to the rest of x"] 
<_ :result <plus <1 .x> .result» 

;"the body of the loop is to add the first element of 
x into the result"»> 

<♦ 3 {rest {** 5 6) J 7> evaluates to 21 
<♦ 3 2 «> evaluates to 9 



<ACTCB-FUNCTIGK 

[Jobjectj I tail 1 llocativel Jchoicel -functiom- 
declarations-] -body-> is exactly like the function F0HCT1OH except 
for the folowing: 

It is treated as an actor in pattern matching. 

The first argument J object I is the matching object. 

Ihe second argument I tail | is a tail of the matching object or <> 
for an element call. 
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/""^ the third argument | locative 1 is a locative to | object | or <> if 
none such exists. 

the fourth argument I choice! is not false only if the actor- 
function gets its choice hew auch to Batch. 

The value of the actor-function is the rest of the object yet 

to be aatched* Actor functions are useful as in internal interface 

between actors and functions. 



4. J*. 2 Macro Procedures 

Macros are expanded by the interpreter and by the compiler. 
The results are respectively interpreted and coopiled. Hacro 
procedures look like 

<BACBC 

Jf cnal-paraaetersj -expressions- > The expansion of 
the aacro is the value of the last expression. The character !• is 
used to suppress invocations. For exatple whereas <♦ 2 2> evaluates 
to the HOHBER **, !•<♦ 2 2> evaluates to the function call <♦ 2 2>. 
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<define choploc <aacro [ f x] 

! f <f>utloc 

• X 

!Krest !*<in .x>»» 

The aacro choploc will take a location as its arguaent and cause the 
contents of that location to be changed to contain the rest of the 
previous contents. 

<choploc <at y» expands to <putloc <at y> <rest <in <at y»» 
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We could have defined the function ♦ as a macro as follows: 



<define «• <macro forest" f x] 

; w let x be the vector of unevaluated arguments 1 ' 
<rule .x 

[<empty> 

; H if x is <♦> then the answer is 0" 
0] 
♦declare 
[[first rest] 

; fl declare identifiers first and rest" 

[xfirst !:rest] 

; M otherwise let first be the first argument and 

rest be the rest of the arguments" 
! f <plus .first !«<♦ !.rest» 
; M the answer is written out using 

binary plus instead of +"]»> 

Thus 

<+ 3 2 4> expands to <plus 3 <plus 2 <plus 4 0»> 



4.4.3 Actor Procedures 

Actors are used in patterns to match values. The primary 
difference between functions and actors is that functions produce 
values while actors match them. Actors and functions take their 
arguments in an exactly analogous fashion. Examples of actors are 
found in section 4.5 below. 

<ACTOB 

♦checker + ^activation- name* Ifunction-declaraticnsj 
patterns->, where ♦activation-name* and ^checker* are optional, 
evaluates to an actor which when it is invoked f matches an object 
which matches all of the -patterns- after the identifiers in the 
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|f unction-declarations) are bound. The |f unction-declarations| is 
interpreted EXACTLY as in FUHCTIOB, 

«actor [-"rest 11 x] <2 .x» 1 a 3> Hatches only a 

«actor f> w rest M f x] <2 .x» a <♦ 3 4> c> matches only <♦ 3 4> 

«actor [x] .x> 3> matches only 3 

«actor [x] .x> a> Batches only a 

. «actor !-fix £[!=fix x]] .x> <♦ 2 2>> Hatches only 4 where 
!^fix is <OF-TIPE ftx>. JJ 

«actor !*fix [[ !=*fix x]] <♦ .x 1» 2> matches only 3 

«actor !«fix £[ !-fix x3 [!=fix y]] <♦ .x .y» 2 3> matches 
only 5 

«actor [£ !-fix f x]] .x> 3> matches only 3 
«actor [ f x] «x> a> matches only a 
«actor [ f x] .x> O 2 2» matches only <♦ 2 2> 
4*4.4 Type Procedures 

Type procedures are used to define nev types* Nev types can 
he defined by the anion, direct product, and direct sum of already 
defined types. Types can also be defined as procedures by patterns. 

<def ine empty <either f) [ ]» 

Define empty to be either an empty list () or an empty vector 
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<define aonadic <either <nuaber> !=atoa <empty»> 

Define the type aonadic to be a naaber or atomic or an eapty 
structure. 

<def ine property-list <actor <list> [ ] 
<star <!*atcn <?>)>» 
A property list is a list of two element lists whose first eleaents 

are atomic* The actor STAR is the Kleene star of regular expressions. 
For exaaple the following are property lists: # ({a (3))) # and ((p1 
4) (hello (r 3))). 

4.4*4*1 Union of Types 

<EITHBB 

-alternative- types- > is a type which aust be one of 
the alternative types. Por exaaple we can define the type <naaber> to 
be the either <fixed> cr the type of float. A disjunction of types 
expresses a constraint on what can be considered to be of the new 
class. 

<define naaber <either <fixed> !-float» 

<prog [[<n«aber> [x 3]]] 

;"x is declared to be of type <nuaber> and 

initialized to 3" 

<cond 

[<is? !*fix .x> 

yes]» 

evaluates to yes since x is really the of type fix 
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4.1.4.2 Product of Types 



<fB0D0CT 

|type-naae) J kind | |foraal-paraaeters| -projection- 
specifications^ will create a type with nane |type-naae| aade oat of 
Ikindl storage nith J f craal- parameters | as for functions and - 
projection-specifications-. Each (projection-specif icationl aust be 
of the following fori: 

£ | apparent-pro jector-naaesl [(initial I |pat| ] ^checker* 
lactual- projector | ] the (apparent-pro jectnrs-naaesl is either 
a single projector naae or [(identifier! Ui»t~o*-P*°J«ctor- 
naaes| ] where (identifier! ranges over {list- of-projector- 
f^-. naaes|. If ♦checker* is present then only objects which 

natch ^checker* can be stored in the coaponent. Shen an 
instance is constructed, the eleaents are given the value 
1 initial l. Iben an instance is decoaposed, the pattern Ipat) 
is used in Batching. If only J initial | is given then Ipat J is 
assuaed to be the saae as (initial). If the actual projector 
is not specified then the next unused integer projector will 
be used. An actual projector which is a procedure call gives 
rise to a VIRTUAL projector storage for which is not 
necessarily physically present in the data structure. A 
product type can be BE TB ACTED to the |kind| of storage out of 
which it was constructed. The function ?B CD OCT grew out of 
soae discussions that I had with lick Pippinger. 
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<define complex 

<product complex vector [r i] 
[real [.r] <numter>] 
[imaginary [.i] <number>]» 

The type complex (for complex number) is the direct product of type 
<number> with projector real and type <number> with projector 
imaginary* The object complex is actually two procedures: a 
function which is the constructor and an actor which is the 
decomposer. Constructor- decomposers implement the overlap of 
functions and actors. 

<complex 3 4> evaluates to #complex £3 4] where * is the type 
marker 

<retract <coiplex 3 4» is [3 4]. 

* ^ <getc real < complex 3 4» (which computes the real component 
of the complex number 3*41) evaluates to 3 * 

<getc imaginary <ccmplex 3 4» evaluates to 4 

<prog [[<number> a bll 

;"Thxs a cemment. He are 

inside a program. The identifiers a ani h are 
declared to be numbers" 
;"in the assignment statement below 

the pattern <complex _a _b> is matched 
against the expression #complex [3 4 J* 
<_ Ccomplex _a _b> <ccmplex 3 4»> 
a gets the value 3 ~ 
b gets the value 4 



<getc real 



<complex <replace 7> 4> 
<ccmjlex 3 4>» evaluates to 7 



<prog [[ !=complex [c <complex 1 2>1]1 
<getc real .c» evaluates to 1 

We need to be able to get at the locations of the components of a 
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product. The <getc |f rejecter | lstructurej> is used for this 

purpose. The expression <PDTLOC |1J ]x|> sets the location |lj to 
the value |xl and return the value Jx|. 

<prog [[x <coBpJe? 3 4>]] 
* ;"x is initialised to #complex [3 4]" 

<putloc 

<getc real . x> 

2> 

;"x now has the value #complex [2 4] w > 

We can define a lower triangular Batrix initialized with zeros 
as follows: 



<define triangular <product triangular vector [n] 

[i <thru 1 •»>] 

/~\ t 

F <i vector .i <f unction [j] 0» 

; w each component is initialized to 

a zero vector of length i M ] 

<ivector .i> 

;"each cosponent must be a vector 
of length i"]» 

<triangular 1> evaluates to itriangular [[0]] 
<triangular 2> evaluates to Itriangular [[C] [° 0]] 
<2 <triangular 2» evaluate to {0 0] 

We can define the type PDP-10 instruction as follows:"" 

<define instruction <product instruction fix 

[op ace indir index addr ] 

[opcode [.op] !*fix <bits 9 27>] 
[accumulator [.ace] !=fix <bits 4 23>] 
[indirect [.indir] !=fix <fcits 1 22>] 
[index [.index] !=fix <bits 4 18>] 
[address [.addr] !=fix <bits 18 0> ]» 

A POP- 10 instruction has 9 bits of opcode which are 27 bits from the 
right end of the word, 4 bits for accumulator number , 1 bit to 
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indicate indirection* 4 bits for index register number, and 18 bits 
for an address. An instruction with opcode 172 and 4 in the 
accumulator field causes the machine to halt, fe can construct such 
an instruction with instruction 172 4 C 0> which evaluates to 
♦instruction 254400000000 in octal. 

the next example illustrates the use of virtual components. 

<define aobjp-ptr 

<product aobjn-ptr fix 
[1 a] 

[length 

£•1] 
!*fix 

<signed-bits 18 18>] 
[ address 

[.a] 

!=fix 

<bits 18 0>]» 

On a PDF- 10 an aobjn pointer is is word whose left half 
contains the negative of the length of the rest of a vector and whose 
right half is the address of the element of the vector pointed at. 
The trailer is a virtual component which lies just after the vector. 
It can be defined as follows: 

# 

<define trailer <£ unction £x] 
<get 

<♦ 

<getc address *x> 
<- <getc length .x» 
1> 
<getc address •»»» 

<TYPE- VECTOR 

-eleaent-specif ications-> constructs a type-vector 

where each eleaeat specification is of the fora [ltype| 1 value | ] which 
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initializes the apparent component I typej to 1 value |. 

<getc fix 

<type- vector 

[float "above 11 ] 

[fix "below" ]» evaluates to "below" 

<CaARACTEfi-VECIOR 

-eleaent-specifications-> construct a character- vector 
where each eleaent-specif icaticn is of the fora [ 1 character J lvalue]] 
which initializes the apparent coaponent 1 character 1 to lvalue J • 

<putc 

<character- vector 

[ !"a beginning ] 
[!"z end]> 
[ ! "a very-beginning ]> 
evaluates to 
♦character-vector [[! w a very- beginning ] [!"z end]] 

*U4. 4. 3 Extension of Types 

Be need to be able to extend the types of values without 
otherwise altering then. For exaaple 3 oranges are not the same as 
the fixed point nuaber 3. 

<EXTENSIOH 

Itype-naae) (aade-ofp will create a new type |type- 
naae] which is an extension of Jaade-of], le can define the type 
oranges by 

<define oranges <ex tension oranges fix» 
Now <o ranges 3> evaluates to toranges 3* 

<UNEXTEHD 



DIRECT PRODUCT CONSTRUCTION 



<COMPLEX> 




<NUM> 



<NUM> 



DIRECT SUM CONSTRUCTION 



<FRUIT> 





<FIX> 



<FIX> 
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I type- name J > returns the name of the type of which 
J type-name | is an extension. Thns <unextend oranges> evaluates to 
fix. 

Individual elements cf a given type can be retracted by the 
function BETBACT. 

<retract <oranges 3>> evaluates to the fixed point number 3 

Similarly we can define apples by 

<define apples <extension appl fix>> 
Then we can define fruit as the union of apples and oranges. 

<define fruit <either I^oranges !=apples>> 

<oranges 3> evaluates to toranges 3 which is a <fruit> 

/**\ O <oranges 3> <agples 4» is an error because you can f t add 

apples and oranges! To aaa apples and oranges the function * must be 

redefined in a local lexical block. 

<is? <fruit> <oranges 3>> is true 
<is? <fruit> 3> is <> (which is FALSE) 

The actor <AS [pattern! J injector J > will be defined to match 
an object JobjJ only if Jobjl is of the type of the range of 

iinjectorl and J pattern] matches <BETBACT Jobjl>. 

<prog £!=fix org] 

<is? <as :org oranges> <oranges 3>>> 

org gets the value 3 
<is7 <as 4 apples> <oranges 4» is <> (which is FALSE) 

4.4.9.4 Direct Sums 
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functions: 

<SBT-ALiaM 

| identification | 

1 tine | 

|handler| 

| process-to-be-interrupted 1> 

will set an alar a with | identification! which will go off after (tiaej 

interrupting J process-to-be-interrupted J with | handler!. 

<UNSET~ALABH 

J pattern- for- identif ica tion J 

jpattern-for-tiae|> 

unsets all alarms whose identification matches Ipattera-for- 

identification! and whose tiae aatches Jpattern-for-tiae|« 

<SBT-TIHEB 

(process] 

jidentif ication J 

Iruntinej 

1 handler) 

I process-to-be-interrupted J> 

sets a tiaer for | process] with Jidentif icationj which will go off 

after iruntiael interrupting | process- to-be- interrupted! with 
lhandlerj. If 1 process! is <> then the tiaer counts the tiae used 
for all processes* 



<0BSE1 -TIMER 

(process! 

I pattern-for-identif ication] 

Ipattern-f or-runtiae| > 

unsets all the tiaers for 1 process | whose identification Batches 

1 pattern- for- identif ication I and whose runtiae aatches ipattern-for- 
runtiael. 
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4.5 Functions in Expressions 



4.5.1 Definitions of Functions 

Examples of the values of various expressions are given below: 
a evaluates to a 
(a b c) evaluates to (a b c) 
<+ 1 2> evaluates to 3 
[3 {rest (a c) ) ] evaluates to [3 c] 
(a b <♦ 2 3>) evaluates to (a b 5) 
(a b {quote (a b)}) evaluates to (a fc a bj 

If a has the value 3, then ([ (.a) ] b) evaluates to ([(3)] b) 

4.5.1*1 Control Functions 

4.5.1.1.1 Conditional 

<0HFA1SB 

|x|> is the value of }x| if it is not false and fails 
other vise. 

<define unfalse 

<f unction [x] 
<cond 

[-"else* <fail>3>» 
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<0B? 

-dis juscts-> evaluates each of the disjuncts in turn 

until one of thea is not false in which case it is returned as the 

value of the function OR?. Otherwise the value of the function OR? is 
false. 

!%<blcck (<oblist or!-> <oblist>) > 

<define or? <f unction out [-•"rest" f a] 
<repeat [[v <>]] l J 

<cond 

[<enpty? .a> 

<.out .v>]> 

<_ :v <eval <1 .a>» 

<cond 

<.out •v>]> 
<chop a»» 



!%<end-block> 



<0B 



•aisjuncts-> is exactly like OH? except that if none 
of -aisjuncts- is not false then a siaple failure is generated. 

!X<block (<oblist or!-> <oblist>) > 

<aefine or 

<f unction [-•"rest" f a ] 

<unfalse <or? !.a>>» 



!*<ena-block> 



<AHD? 



-conjuncts-> evaluates each of the ccnjuncts in turn 
unless one of then is false in which case it returns the value false. 
Otherwise it returns the value of the last conjunct. 
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!%<block (<oblist and!-> <oblist>) > 

<define and? <f unction out r-."rest" »a] 
<repeat [£v -."true" j ] 
<cond 

£<enpty? .a> 

<.out .v>]> 
<_ :v <eval <1 .a>» 
<cond 

[<not? ,v> 

<.out <»]> 
<chop a»» 

!%<end-blocx> 



<AHD 



-conjuncts-> is exactly like AND? except that if one 
of the -conjuncts- is false then a siaple failure is generated. 

!%<block (<oblist and!-> <oblist>) > 

/~\ <aefine and . .... . , 

r <f unction [-"rest" 'a] 

<unfalse <and? !.a»» 
!%<end-block> 



<HOT? 



<BCT 



|xj> is true if Ix| is false and otherwise JxJ 



<define not? 

<f unction £x] 
<cond 

£.x <>] 

£-.«else" -"true"]>» 



]x|> is true if Jx| is false and fails otherwise. 



<define not 

<f unction £x] 

<unfalse <not? .x»» 



/*> 



4.5 page 94 

<CCND 

♦checker* ♦ activation- name* -clauses-> is the 
conditional statement of the language. Each clause is of the form 
[predicate -body-] or cf the form iDECLABE [[-declarations-] predicate 
-body- ]. The predicate of each clause is evaluated in turn until one 
of them is not false. Then the rest of the elements of the clause are 
evaluated in turn with the value of the last element being the value 
of the function COND. If all the predicates are false then the value 
of the function CCND is false. The function COND is due to John 
McCarthy. 

<cond [<> 5]> evaluates to <> 
<cond [<> 5] [-."else" 6]> evaluates to 6 
If the operator | is used in fron of a clause then the predicate of 
the clause may be evaluated before or after the predicate of the next 
clause or in parallel mith it. The first predicate to converge to 
anything other than false wins the race. There are obvious timing 
errors in the indiscriminate use of J for clauses 

<cond |[3 a] £i» b]> evaluates to either a or b 

<C1TCH 

♦activation-name* 
£ - declarations- ] 

Clkl V«TnpXE« |v| ] 
-body-> 
establishes a catchpoint and then attempts to evaluate |x|. If the 

evaluation of jx| comes back mith an abnormal exit then the catchpoint 
is removed, jkj is bound to the type of exit and -body- is evaluated. 
If control runs off the end of -body- then the abnormal exit is 
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restarted. The abnormal returns which are currently defined are of 
the following argument tuples: 

r^"RESTCBE" |activation| -values-] for a restoration of the 
tailpoint | activation J with -values-. 

r -"EXIT-CALL" If! largumentsl] for a non, local exit call of If J. 
The expressions |f | may be either an activation or a junction. 

[-"EXIT" |activaticnl J values! ] for a non local exit to 
lactivationl with -values-. 

[-"AGAIN! 1 lactivationj ] for a non local reiteration of 
lactivationl . 

[-"TEBBIBATE" ] for a termination of the process 
For example 

<prog [ ] 

<prog f oo [ ] 
fS <catch { ] 

<.foo 3 a> 

;"exit .foo with 3 and a" 

[k -"rest" v] 

<cond 

[<is? .k -"exit*> 
<«bar 

<print 

(caught 
exiting 
with 

prints (caught exiting with [3 a]) and then evaluates to a 

<+ 

<catch [ ] 

[k -*rest" v] 
<cond 

[<is? .k -«fail"> 

<print "you can«t get here!">]» 
<print 5> 
<fail» 
prints 5 and then fails without printing anything more. 
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<catch [ ] 

<♦ <print 4> <fail» 
[k -* w rest lf v] 
<cond 

[<is? .k ^»fail«> 

<print (caught failure) >]» 
will print 4, print (caught failure) , ana then continue failing* 



<FAILP€1NT 

♦checker ♦ 
♦activation- naie* 
[•declarations- ] 
Jexpr 1 

[♦message ♦activation*] 
-body-> 
establishes a failpoint and then evaluates Jexpr). If the evaluation 

does not produce a failure then the value of the function FAILPOINT is 
the value of Jexpr J. If the evaluation of Jexpr | or some subsequent 
evaluation ultimately fails back to the failpoint then the failpoint 
is disestablished, the identifier J message 1 is bound to the failure 
message, the identifier ] activation! is bound to true if the failure 
is to a higher level activation, and -body- is evaluated, 

<failpcint [ ] <f ail> £* a] 
<print hello>> 
prints hello and then restarts failing 

<failpcint r j 3 £m a] 

<prxnt V?> evaluates to 3 but if a failure 
ever backtracks to here 
then 4 will be printed, 

<prog foo 

<failpoint [ ] 9 [■ a] 
<.foo a> 

;»exit .foo with a*> 
<fail» evaluates to a 

<RESTOBE 

I activation J -values-> will restore the failpoint 
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naaed by Jactivationj and exit it with -values-/ It is an error if 
| activation | is not the activation of a failpoint. The function 
RESTOHE is. due to Drew HcDeraott. 

<prog way-out [[a 3]] 
<print 

<failpcint out [ 3 .a [a a] 
<cond 

[<is .a 5> 

<• way-cut #a>] 
[^"else" 

<restore *out *a>]>» 
<inc! -persistent a> 

<fail» initializes a to 3 # prints 3, 
increments a to <*, fails back into the failpoint, restores the 
failpoint, prints **, increaents a to 5, fails back into the failpoint, 
and finally exits .way-out with the value 5. The following function 
does not represent good prograaaing practice and is not original, but 
it dees illustrate the use of HBSTOHE* The function <CHANCBS 
]identifieri |exceededj> will decreaent the value cf Jidentifierj each 
tiae a failure propagates through it until the value of Jidentifierj 
becoaes less than or egual to zero at which point | exceeded! will be 
evaluated* 

!%<block (<oblist chances!-> <oblist>) > 

<def ine chances ^ mji ^ ^ £ , .. r . • ^ ^^ 

<f unction [ f i -*"optional w [ f e f <error>]] 

<failpoint f [] <> [^"optional* ] 
<_ :.i <- .,i 1» 
<cond 

[<is <less= 0> .*i> 

<eval .e>] 
[ -•"else* 

<restore .f . .i>]»» 

!S<endblock> 



<BULE 

♦checker* ♦activation-naae* [-declarations-] |x| - 
clauses- — ••'ELSE 11 - -nct-found-> where the +activation-naae* and 
♦checker* are optional gives a rule for the expression Jx|* Each 
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clause is of the form [JpatternJ -body-] or of the form #DECLARE [£- 
declarations-] J pattern j -body- J. The value of Jx} is matched against 
the pattern of each clause until a match is found. If there is only 
one element in the clause then the value of the function BOLE is <> 
which is false. Otherwise the value is the value of the last element 
of the clause. If none of the patterns match then the value of the 
function BULE is the value of -not-found- if it exists or is <> (vhich 
is FALSE). If a clause is preceded by | then the (patters I of the 
clause may be matched against Jx| before or after the pattern of the 
next clause or in parallel with it. If more than one J pattern | 
matches then the first one to match wins the race. 

<rule £] 3 [!-fix]> evaluates to <> which is false 
<rule [x] a £_x (.x .x) ]> evaluates to (a a) 
<rule [] c l& e]> evaluates to <> 
<rule [] h [1 a] [hb][3c]> evaluates to b 
<rule [ ] <- 3 1> £1 b] £<♦ 1 1> c] -"else" 5> 

evaluates to c 

<rule £] a [b 3] -."else' 1 7> evaluates to 7 
<rule £] a £b 3]> evaluates to <> which is false 
<rule £] 5 |[<greater 3> "big"] £<less 7> "small" ]> 

could evaluate to either "big" or "small". 

4.5. 1.1.2 Block 

<DECLABE 

-declarations- > declares new top level local 
identifiers within the process which calls DECLARE, it returns a list 
of the identifiers declared. 
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<ACTCB-CA1LEB 

lobjectj 

Itaill 

| locative | 

(choice 1 

| pattern! 

|bindings-f or-pattern J > 
enables functions to call the pattern aatcher to match 1 pattern! 
against objects efficiently in special cases* 

<CALL 

1 junction-name J 

[<jfl -send-args-> 1 state-pa th-for-f 1 Jrecommendation- 
for-f \ ] 

igl> 

binds the identifier 1 junction-name J to the junction defined by CALL 
f"^ and then calls lf| with the specified arguments. The expression |fj 
may be any of the following: 

a label function which will be invoked. 

a process which will be resumed. 
a function which will be invoiced, 
a port in which -send-args- will be gueued. 
an activation which will be exited, 
a junction which will be invoked. 

a pattern which will attempt a pattern directed invocation 
The recommendation must be of one of the following forms: 

0"USE* -pats-] says that function which matches one of the 
patterns -pats- BUST be used. 
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|>*TRY W -pats-] sas that the functions which match the 
pattterns -pats- are be tried* 

[^"FILTER" |h|] syas that the functions 

<1M 

KCAHDIEATES FUMCTIOH |f| Jstate-path-for-f |» 

are all to be invoked (possibley in parallel) • 
An ordinary function call <jf | -args-> is equivalent to 

<CA1L 

<lfl -args-> 
<F0HCTIOH £y] .y» 

where y is arbitrary identifier* The fora of the argument |g| as a 
function is due to Jerry Sussaan. However , if |gl is of the fora 
[1 function! Istate-path] then it allows for a pattern directed 
resumption through |state-path| . lie can define a function idivide of 
n and d which returns the quotient and remainder of the integer 
division of n by d. 

Cdefine idivide <f unction idivide [n d] 
<repeat 

[[r .*] [g 0]] 
<cond 

[<is? <less *n> .r> 
<«idivide *g .r> 

;*exit .idivide with *g and .r*]> 
<_ :r <- .n .r» 
<inc g»» 

How if we evaluate 

[a ! {idivide 7 31) b] evaluates to [a 2 1 bj 

<call 

<idivide 7 3> 
<f unction £a b] 

<print .a> 

<print .b>» prints 2 and then prints 



f^s 
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<CAIL 

| junction-namej 

<jf| -arguments- > 

i9t 

|state-path)> 
where |f| is a label procedure exits tc the level where the label 

function |fj is defined and then invokes JfJ with the specified - 
arguments-. The expression <Jf | -arguments-> is an abbreviation for 

<CA1L 

<|f| -arguments- > 

<PD8CTIOH OUT [-"TUPLB* I] <.0UT !•!>» 

Label procedures and junctions are generalizations of labels* label 
procedures are defined using the -'•"LABELS" construct in block 
declarations. See the example under PBCG. The function |g| is 
applied to the values received if the process which calls CALL is 
resulted. Executing <• J junction* name l -send-args-> will exit to the 
level where ] junction-name | was defined and then invoke <|g| -send- 
args->. If the optional argument ]g| is not present and If J is 
defined in another process then the process which calls CALL is 
terminated. 

<TEHPOBARI 

] junction- name 1 <|f| -arguments> }g|> makes a CALL to 
|f | such that all the tentative side effects within the scope from the 
point of the call to the exit of |f| are undone. 

<prog [[x 0]] 

<temporary 

«f unction [ ] 

< x «> 

; "tentatively set x to 4">» 
;"x is restored to because the 
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call was temporary" 
•x> evaluates to 

<TEHPORIZB 

(activation 1 - values- > exits \ activation) with - 
values- undoing all the tentative side effects within the scope of 
| activation! • 

<prog {[x 0]] 

<prog out [ ] 

< x *§> 

; "tentatively set x to ft* 
<temporize .out> 

;*exit the activation .out undoing all 
the tenative actions in 
the scope of the activation"> 
•x> evaluates to 

<prog 

U* 0] 

•** labels* 

[f <f unction £ } # x>] 
; "define f to be a label 
function of no 
arguments that returns the 
value of x ] 

< x ft> 

; "tentatively set x to ft" 

<tenjorize .f> 

; "invoke the label function . f 

undoing every thing which 

is tentative that has been dome since 



was defined"> evaluates to 



<prog [[x Ojy 



<call out 
< 

<f unction [w] 

< x .*> 

Ctenporize .out .x» 
ft> 
<f unction [y] 

<print .x> 

<print .y»» will print 

and then print ft 
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<ST*AIGHTB8 

<|f| -arguaents» sakes a Clll to Jf | suck that a 
siaple failure will not be caught vithin the scope free the point of 
the call to the exit of Jf I. the function STHAIGBTBH grew out of 
discussions that I had with 3eff Hill and Terry linograd* k very 
similar concept is called "fast hack" in parsing gran mars. The 
expression !s(fora| is an abbreviation for <STHAIGHTEB ]fora|>. 

<prog £[a 3] b] 
<_ 

<vel _a b> 
*t> 
<print .a> 
<cond 

[<is? .a «> 
<f ail> ]> 
^hp^ «b> assigns a the value 4, prints <t* fails 

back inside vel restores a to have the value 3, assigns b the value 
4 # prints 3, and then finally evaluates to 4, 

<prog £[a 3] b] 
ls<_ 

<vel _a b> 

4> 
<print .a> 
<ccnd 

[<is? .a H> 
<f ail> ]> 
•b> assigns a the value 4, prints 4 r falls 
back through _ since it has been straightened but restores a to have 
the value 3 in the process, and thus the whole prog fails. 

<STRAIGBTEH-0P 

| activation! > straightens the investigation by setting 
up a failpoint which vill convert a sin pie failure into <?AIL 
| activation | >. 
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<define straighten-up <f unction [activation] 
<failpoint .activation 
[message activa] 
<cond 

[<not? <or? .aessage ,activa» 
<faii <> .activafcion>]>>» 

<PERSISTBNT 

| junction- naiej <]£| -arguments> |g|> aakes a CA1L to 
| £ | such that all changees vithin the scope froa the point of the call 
to the exit of |f | are persistent* That is they trill not go a nay 
automatically by backtracking . The expression !p|fora| is an 
abbreviation for <PEBSISTBHT |fora|>. 

<prog out [[a 3] b] 

<failpcint []<>[■ a] 
<cond 

[<is? .a 3> 

<«out "win*>] 
[-•"else" 

<print [a changed to .a]> 
<.out "lose">]» 
<_ <vel _a _b> 4> 
<print .a> 

<fail» initialises a to 3, tentatively alters 
a to 4, prints 4 # fails back inside vel, restores a to 3, tententavely 
alters b to 4 # print 3 # fails back to the fail point, notes that a is 
still 3 and so exits the activation .out with "win". 

<prog cut [[a 31 b ] 

<faIlpoi:nt [ ] <> [a a] 

<cond 

[<is? .a 3> 

<.out *win">3 
[-•"else" 

<print [a changed to .a]> 
<.out "lose">]» 
!p<_ <vel _a _b> 4> 
<print .a> 

<fail» initialized a to 3, alters a to 4, 
prints 4, fails back into the f ail point # notes that a is no longer 4, 
and so sex its the activation .out vith "lose*. 
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<IS? 

jpatternl i expression 1 jis-table] ]is-apply-table]> is 
true only if | pattern! matches the value of 1 expression J . The |is- 
tablej aust be a TYPE-VECTOR and so lust the | is-apply- table | . The 
function IS aatains twc lccal identifiers TABLE1-IS and iPPLI-TABLB!- 
IS which are respectively bcund to jis-tablej and |is-apply-table|. 

<IS 

Jpatternl J expression! J is- table! ]is-apply-table|> is 
true if jpatternl Batches the value of |expression| and generates a 
simple failure otherwise. 

(pattern] {expression] > is an assigneent statement* 
^ The value of the function _ is the value of (expression). 

<block (<oblist assign!-> <oblist>)> 

<define . , 

Xf unction [ f pattern value] 

<eval I'Cis .pattern f .value» 

.value>> 

<endblcck> 
< BATCH? 

Jpatternl] ] patter n2|> is true if Jpatternl | Batches 
| pat tern 2 | and is false other vise. 
<HATCH 

Jpatternl] J patter n2J> is true if |pattern1| Batches 
|pattern2| and generates a siaple failure otherwise* 
<E?AL 
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|x| |b| |apply-table|> evaluates | x| using the 
bindings Jbj to look up the values of identifiers and |apply-table| to 
apply objects according to their types. The (apply-tablej aust be a 
TIPE-?BCTOB. The function EVIL aaintains local identifiers TaBLB!- 
EVAL and APPlI-TABLEJ-EVal to hold the current jeval-tablei and 
|apply-table| respectively. 
<QU0TB 

|xj> is |x|. fe nay abbreviate <Q0OTE |xf> as *|x|. 
For exaaple <prog £[x 1J] •<+ .x 5» evalutes to <♦ .x 5>. lot ice 
that according to the following definition QUOTE write protects its 
arguaent. 

<define guote <f unction [•xj ,x» 
<SUPPBESS 

lx}> suppresses evaluation of the fori |x|. Be nay 
abbreviate <S0PPRBSS Jxl> as !»|xj. Por exaaple <prog £[x 1}] !•<♦ .x 
5» evaluates to <♦ 1 5>. 

<PB0G 

♦checker* +activation-naae* J declaration- 
specification j -body-> where the +activation-naae+ and ♦checker* are 
optional is a aaaed program block. The | declaration-specification | is 
of the fora 

[-ordinary-deciarations- 
-»"iABllS" -label-declarations 
-."IHTEHHALS" -internal-declarations- ] 
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where LABELS and INTEBHALS are optional. 

Each linternal-declaraticnj is of the following fora: 

[|f! <F0HCTICH Jforaal-paraaeters] -body->] the identifier |f| 
is declared to Be an internal function* As such it has 
special access to the local identifiers of the procedure to 
which it is internal. The identifier ]f | lay not have its 
value changed. The following constructs are very efficient 
within the procedure which delares |f| to be internal: 

<|f| -arguaents-> 
{jf j -arguments-} 

I {If J -arguments-!} 
Internal functions provide a rapid means of conaon 
subexpression evaluation. The current fora of internal 
functions is due to Peter Bishop and Dave Beed. 



j^*^ Each I ordinary- dec la rat ion j is of the following fora: 

[ fat tribute-specification] -bindings-] causes the ideatifers 
in the bindings to be rebound with the appropriate (attribute- 
specif icat ion | 

where each binding aust be one of the following two foras: 

{identifier! indicating that the identifier is rebound and 
not assigned a value 

[ f identifier! lvalue)] which rebinds the (identifier! with 
an initial J value | 



where {attribute-specification } aust be one of the 
following: 

lattributej where each (attribute! aust be one of the 

following: 

(pattern) indicating that the value of the 
identifier aust aatch I pattern |. A coaaon pattern 
is <0P-TIPB ftype~naaej> (abbreviated !«|type- 
naae)) which indicates that the value of the 
identifier aust be of type ]type-naae|. 



r^ 
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^"SPECIAL" indicating that each of the identifiers 
is special meaning that it can ba used as a free 
identifier in other procedures 

[-attributes-] 

Each J label-declaration | is of the form 

[Ifj Jfuactionl] so, that execution <jfl -arguaents-> rill 
cause centre! to exit to the poxnt where jf j was declared and 

|f unction J to te applied to the evaluated -arguients-. 

If control falls through the bctton of the function PROG then it takes 

as its value the value of the last stateaent of the body* If called 
as a procedure a label exits to the activation in which the label was 

bound. 

<prog foo [[x 1] 
-»" labels* 

[nonfatal 

<f unction [z] 

<print {non-fatal .z)> 
<_ :x a> 
<again •foo»] 
[fatal 

<f unction [2] 

<print (fatal • *)> 
<*foo lose> 
; "exit .foo with 
lose*>]] 
j* we have two label procedures 

nonfatal and fatal" 
<prog bar [[y .x] [x 1]] 
<cond 

[<is? .y 1> 

<. nonfatal first-tiae>] 
[-"•"else 11 

<• fatal second-tiae> ]>» 

evaluates as follows: 

foo is entered 
x is initialized to 1 

the labels fatal and nonfatal are bound 
bar is entered 
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y is initialised to 1 
x is initialized to 1 
<. nonfatal first-tiae> is invoked 
causing us to 
exit EAB 
(non-fatal first-time) is printed 
x is changed to a 

bar is entered 
y is initialized to a 
x is initialized to 1 
<♦ fatal second-tiae> is invoked 
causing us to exit FOO 
(fatal second-tine) is printed 
foo is exited with the value lose 



<BLOCKBIHD . r _ , 

♦checker* ♦actavation-naoe* [-declarations- J 

[^"BINI* Jblock-bindingsj 

Jrelative-bindings 1 

jblock-na»e| 

1 block-declarations | 

Jagainer | ] 

fs -body-> 

is exactly like PROG except that before the -body- is executed a name 

jblock-naaej and a set of block style (e.g. PBOG, FOR, etc.) bindings 

| block-declarations 1 are established using | relative-bindings | to look 

up the values of any free identifiers. The resulting binding 

environment is bound to the identifier | block-bindings |. If <AGAIN 

|block-naael> is called, then Jagainer J is invoked. The function 

BLOCKBIHD is useful for writing interpreters* le could define BEPEAT 

as follows: 



<def ine repeat ^ 
<functlon p2 

[-"bind 11 b1 [ f na«e • decs -**rest" f bd]] 

;"let b1 be the bindings before p2 was entered 

and let naie be the nawe of the repeat, 

decs be its declarations, 

and bd be its body 91 
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<blcckbind p1 [[iter -bdj] 

; w let iter be the rest of the body 
to be evaluated" 
[^*bind* b2 

• b1 

• name 

• decs 
<prog [ ] 

<_ 2 iter .bd> 
;*if <again .nane> 

is executed, 
then reinitialise 
iter* 
<again *p1»] 
<ccnd 

[<enpty? .iter> 
;"if the body .iter is eapty* 
<_ :iter .ba> 

;"set iter to be the whole body* 
<again *p1>]> 
<eval <1 .iter> .b2> 
<chop iter> 

;"set the body iter to the rest of itself* 
<again .p1»» 



<PROCBIND 

♦checker* +activation-naae+ [-declarations-] 
[^••BIBI* J procedure- bindings 1 
J relative-bindings] 
Iprocedure-naae] 
I procedure-declarations] ] 
-body-> is exactly like BLOCKBIHD except that it takes 
procedure style declarations (e.g. FOHCTIOB and ACTOB) instead of PROG 
style declarations* 

4.5.1.1.3 Escape 



<CALL 

( junction- naie] 
< | activation f -values-> 
If! 

]state-path|> 
leaves the activation (activation] with the given values. The 

expression < (activation] -values-> is an abbreviation for 



f~\ 



r\ 



«.5 page 111 

<CAIL 

< | activation l -values-> 

<FDSCTIOH [X] .X» 
where I is an arbitrary identifier. The function Jf| is applied to 
the values received if the process which calls CALL is resumed* If 
the optional argument |f | is not present and ♦activation-name* is 
defined in another process, then the process which called CALi is 
terminated. 

<AGAIH 

{junction- name} | activation] Jf|> reiterates the 
| activation J „ If {activation | is an activation in another process, 
then the process which calls AGAIN will apply the function |f I to the 
values with which it is resumed. If the optional argument |f | is not 
present and {activation! is defined in another process, then the 
process which called AGAIH is terminated. It is illegal to execute 
<AGAIN ] activation | > until all the declarations of 1 activation | have 
been processed. 

<prog f oo [ ] 

<priut 1> 

<again .foo» prints 1 and then prints 
1, prints 1, etc. 

<prog bar [[a <again .bar>] [b 3]1 ^^ 

<prlnt (you can't get hefe)» causes an error 

<FAIL> generates a simple failure in the match. 

<FAIL 1 message J > causes a failure with a (message) to be 

reported above. A failure with a message can be caught only by the 
function FAILPCIHT which is explained above. 
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<FAII 

I message! J place I |£|> generates a failure to | place | 
and then a failure with a | message j from there, the } place] may be 
either a process or an activation* The function |f| is applied to any 
arguments received by being resumed by another process* For example 
down inside a function whose activation is la) and which has been 
called with a pattern directed invocation executing <fail ^"caller" 
Jap will signal that none of the other alternative functions should 
be tried. 

4.5. 1*1.4 Repetition 

<REPEAT 

♦checker ♦ *activation-name+ [-declarations-] -body-> 
where the ♦activation-name^ and ♦checker* are optional executes the 
body repeatedly until the body is exited by calling one of the 
functions CALL or AGAIN. Iterative programming in terms of repeats 
has the advantage that all loops are necessarily nested. The repeat 
loop may be exited with the value x by <.+activation~name+ x> where 
♦activation-name* is the name of the repeat loop. Executing <AGAIM 
. ♦activation-nameO after -declarations- have been processed transfers 
control to the first element of -body~. 

<F0» 

♦checker^ ♦activation-name^ [-declarations-] 

[[-"iaiTIAI.* -initial-action-] 

["•••STIP" -step-action- ] 

[-"TEST* 1 predicate | -test-action-]] 



f\ 
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-body-> 

where the ♦activation-name^ and *checker^ are optional is defined to 
be an abbreviation for the following: 

<PBOG ♦checker* ♦activation-name^ [-declarations-] 
-intial-action- 
<BEPEAT [ ] 

<CORD 

[ J predicate | 

-test-action- 
<.+activation-nane^ <>> 
; H exit .♦activation-name* with <>*]> 
-body- 
- step-act ion-» 

The FOB loop may be exited with the value |x| by <.*activation-name* 
|xl > where ♦activation- name* is the name of the FOB loop. Executing 
<AGAIH ♦ activation-name^ jumps to the point labeled AGAIH in the 
expansion above. Alternatively # we have 

<FOB ♦checker^ ♦activation-name^ [-declarations-] 
[[-"MITIA1" -initial-action-] 

[-"TEST* ipredicatej -test-action-] 

[^"LIST" litem! v»if" jconditionl ] 

[-•"STEP" -step-action-]] 

-body-> 

where the ♦activation- name* and ♦checker* are optional is like the FOB 
loop previously described except that the value of the for statement 
is the list of all the items such that the condition is true. It is 
equivalent to the following although it is implemented much more 
efficiently because it only does one cons for eacn item in the value. 
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<*0R 

♦checker* 
♦activation-nane^ 
[ -declarations- 

[ COLLECTED {)]] 

; "declare COLLECTED to be initialized to * 

[[-"INITIAL" - initial-act ion-] 

[-"TEST* 

J predicate} 
-test- action-* 

<• ♦activation-nane^ .COLLECTED> 
;"exit ♦♦activation-nane^ 
with •collected 19 ] 
[-"STEP* 

<COHD 

[ (condition) 

;*add |itea| onto the end of 

COLLECTED if condition 
is net 91 

: COLLECTED 
(! •COLLECTED 
JitenJ)>]> 

-step- action- ]] 

-body-> 

In addition to being able to list the elenents produced we can append 
or concatenate then* 



<FjOA ♦checker* ♦activation-name* [-declarations- ] 

[[-•01* J pattern! | value] -final-action- 1] 
-body-> 
where the ♦activation- cane* and ♦checker* are optional executes the 

body of the loop once for each tine that pattern natches value, <REST 
valne>* <RBST value 2> # etc* until <BEST value n> becones enptj. 



<P0B 

♦checker ♦ ♦activation-nane^ 

[-declarations- [X lvalue) ]] 

[[-"TEST" 

<IS? <EHP1I> .%> 

;"if X is eepty then quit" 
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-f inal-acticns- ] 
[-."STEP" 

;"set I to the rest of X" 
<CHOP X>]] 
<CCID 

[<IS? 1 pattern | *X> 
-body- 
;*if | pattern | Matches X 

execute -body* ]» 

<FOR ^checker* ♦activation-naie* [-declarations-] 

[[-•"IH" (pattern] 1 value | -final-action-]] 
-body-> 
where the ♦activation-naae* and ^checker* are optional executes the 

body of the loop once for each tine that pattern latches <1 | value |>, 
<1 <REST |valuel» # <1 <REST lvalue! 2», etc. until <RRST lvalue! n> 
becoaes enpty. The ^"IN* variant of a FOR loop was invented for LISP 
II. The above expression is equivalent to: 



f^. 



<FOR ♦checker ♦ *activatioa-nane* 

[-declarations- [X | value)]] 

[[-i«TBST« 

<IS? <EHPTY> •!> 

;*if X is enpty then qait* 

| final- actions | ] 

[-"STEP" 

;"set X to the rest of X" 

<CHOP X>]] 

<COHB 

[<IS? Jpatternl <1 *X» 

•body- 

;"if J pattern J natches the 

first elenent of X 

then exucute -body-"]» 

For ex an pie we can define a function which returns the reverse of a 
list as follows: 

<define reverse <f unction rev [x] 
<for [first [answer () ]] 

[[-•in* : first „x] 
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[^"final" 

<«rev «answer> 

; M exit .rev with • answer" ]] 

: answer 

(•first ! . answer) »» 

Thus < re verse (a b c)> is (c b a) The following function returns a 
list of the fixed point numbers in its argument: 

<define numbers <f unction [x] 
<for [£!*fix first]] 

[["•"in" :first *x] 
[-"list" .*]]>» 

Thus <numbers (4 a (3 4) 5.0 6 [3])> is (4 6). 



<F0B +checker+ ♦activation-name* [-declarations-] 

[[-**IHC W Jj| -"BY" JiJ -."DHTIL" | predicate! ]] 
-body-> is equivalent to 

<FOB ♦ checker* *activation-name+ [-declarations-! 
[[-"TEST" Jpredicatej] J 

[-"STEP" <IHC JjJ JiJ>]] 

-body-> 



<P0B *checker* +activation-name* f -declarations- ] 
£[-"THC" JjJ -."BY" Ji| -"*HBU" Ilimiti]] J 
-body-> is equivalent to 

<POB ♦checker* *activation~name* 
[-declarations- 

[S <IBS li|>] 

[1 Jlimitl]] 
;"S is the absolute value of the step 

si^e which is frozen on entrance 

to the FOB loop" 
;"the limit X is also frozen 

on entrance to the FOB loop 19 
[[-"IHC" J jj -"BY" .S 
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-"ONSIL" 

<IS? <GBBATEB .£> Ij|>]] 
-body-> 



<POH ^checker* *activation-naae+ r-declaratioijs-] 

[[-•••DEC" |jl -••BY" iij - n IJNTIL* | predicate | ] ] 

-body-> is equivalent to 

<FOB ^checker* *activ at ion-name* [-declarations- ] 
[[-•"TEST" Jpredicatel ] 

[-."STEP" <DEC }j| IH>]] 
-body-> 



<POB ♦checker* *activation-naae+ [-declarations-] 
[[-."DEC" Jjl -."BY" |i| -"THBU" lliaitj]] 
-body-> is equivalent to 

^^ <POB ♦checker ♦ ♦activation-naae* 

[-declarations- 

[S <ABS ii|>] 

[L UiaitJ]] 

[[-•"DEC* |j| -"BY* .S -."OHTIL* <IS? <LESS .L> 

I J I > 1 3 

-body-> 

<POB ♦checker* +activation-naae+ [-declarations-] 
[[-"TABU" ]liait|]] 
-body-> is equivalent to: 

<FOB ^checker* ♦activation-naae* [-declarations- [I 

1JI 

[[-"IHC* I -."THBO" <ABS Jliait|>]] 

-body-> 



4«5.1*i*5 Hulti-Process 
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Often it is convenient and more efficent to have aore than one 
HATCHLESS process in existence at one time. By a process we i«an a 
prograa counter together with a stack. Primitives are needed for the 
following functions: 

1. Creating processes 

2. Causing them to run 

3. Teroinating processes 
4* Interrupting processes 

5. Single stepping processes 

<STEP 

lp| Jn | |condition|> executes the process |p| for Jnl 
elementary steps unless the I condition) is let in which case it 
returns immediately. The value of the function STEP is the number of 
elementary steps actually executed in the process |p). The existence 
of the function STEP aeans that PLAHHBB functions are not necessarily 
HOHOTOHE in the sense of lattice theory. h function f mill be said to 
be COHTAIHED in a function g if whenever <f x> converges then <g x> 
converges and furthermore <f x> = <g x>. k function h mill be said to 
be HCMOTCHE if whenever x is contained in y then, <f x> is contained 
in <f y>. 

<I1VQKE 

I junction-name) |p| |n) Icondition) )f)> executes the 
process |p) through )nj complete procedure invocations unless the 
{condition) is met in which case the value is the number of 
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invocations completed. In this case Jconditionj is a function which 
is applied to the values returned by the invocation. After the 
invocations of jp| are complete control retuxns to the original 
process where |f | is applied to the values returned by the last 
invocation in |p|. 
<PBOCESS 

Jf J |tcp-activationl J scheduler J> creates a new 
process which begins execution with the Jf|. The expression <PBOCESS> 
returns the name of the process in which it is executed. Processes 
enable us to have multiple lcci of control. We can hold our place in 
the problem solving process in seme of the processes while advancing 
others. If l f J is a function then the process expects to be resumed 
fS with arguments for \t\ the first time that it is entered. If JfJ is 

of the form [|g| JportJ] then it will hang on IportJ and apply the the 
function ig| to the container of values that it extracts from jport|. 
The |top-activaticnl specifies how much of an existing process must be 
copied to start off the new process. Copying a process enalbles us to 
preserve its current state and still allow it to continue exectuon. 
The process is scheduled by the process JschedulerJ. The value of the 
function PBOCESS is the name of the created process. The garbage 
collector will terminate a process before it collects the storage for 
the process. If a process returns or fails off its top then it is 
terminated. The function Jf | can handle normal returns and failures 
as it pleases, k process has the following apparant components: 
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-"ST AT 0S W is the status of the process. The status is be one 
of the followicg: 

-"BESUWEABLE* -"STOPPED* -"BUNABLE" -"BUNNHfG" 
-"TEBHINATED" 

-"SCHEDULES" is the scheduler cf the process 

-"BUNTIHE" is the runtime charged to the rrocess. 

^"TIMEBS n is a list of timers f$r the process* The structure 
of a timer is explained above in the section en interrupts. 

<CALL 

1 junction- name! 
< | p 1 -send-args-> 
1 function] 
jstate-pathj> 
resumes execution of the process lp| with the arguments -se«d-args~ 

from the point that control last left it and suspend execution of the 
calling process. When the process which was suspended by the CALL 
statement is itself later resumed then the arguments received are 
passed as parameters tc |function|. If the optional argument 
If unctionj is not present then the process which called CALL is 
terminated. The expression <Jpl -send-args-> is an abbreviation for 

<CAL1 

< 1 p i -send-args-> 

<FUHCT0N OUT [-"TUPLE* X] <.0UT !.X>». 

For example «process foo> 2 a> causes <foo 2 a> to be executed in a 
new process. 

An example of the use of more than one process is in computing 
the fringe of an expression* The fringe of an expression is defined 
to be the expression with all interior parentheses removed. For 
example the fringe of (a (b) c) is (a b c) and the fringe of ({a {((b) 
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f\ 



c)))) is (a b c) • We conjecture that the problem cannot be solved in 

pure LISP without the use of the primitives CONS, LABEL, or FUNCTION* 
He would like to write an efficient program to test whether two s- 
expressions have the same fringe . The problem is analogous to testing 
whether two derivation trees for a context free grammar have generated 
the same string. The function fringe? is not intrinsically 
interesting. Its importance lies in that fact that very similar 
control problems arise when a problem solver is trying to extract 
information from two different areas of investigation at once. We 
would like to be able to hold our place in one of the investigation 
spaces while we resume computation in the other, flultijle processes 
give us the capability which we need. The following symmetric form of 
f~\ the definition of fringe? is due to Bob Frankston. 

<define fringe? 

<f unction cut [x y] 
<prog 

[[EX 

<process tree-walk> 

; "create a process which begins execution 
with the function tree-walk 1 *] 
[py <process €ree-walk>]] 
<.px .x <process» 
<.py .y <process» 
<repeat [temporary] 
<cond 

[<—? <_ : temporary <.px» <• py» 
<cond 

[<is? .temporary () > 
<.out -.«true«>]>] 
[^"else" <.out <»]>»» 

<define tree-walk 

<f unction [x p] 
<.p> 
; w the first thing to do is to resume 

^^ the main process with no arguments" 

$ \ - ., ■ . ........ 
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< tree- walk 1 . x ,p> 

; w after doing the complete 

tree walk resume the 
main process with the 
special value () w 

<-F ()»> 

<define tree-walk 1 

<f unction [x p] 

<cond 

[<empty? *x> 

;"if the structure is 

empty then return 
and try to find another atom"] 
[<is? !-atom *x> 

• "resume the main process with the 

atom we have found* 
<*p *x>] 
[-»"else w 

<tree-walk1 <1 *x» 
; w find the atoms in the 

first element of • x* 
<tree-walk1 <rest *x>> 
;"find the atoms in the rest 
of .x and then 
return to finding atoms on 
the remaining branches" ]»> 



<PCBT> 
creates a structure which contains two compon tents: 

EXPORT SI-PORT is a ring which holds a queue of containers of 
exports waiting in the port* 

IMPORTERS! -PORT is a ring which holds a queue of processes 
waitxng to take containers out of the port* 

At any time either or both rings may be empty* Our concept of a port 
is derived from Rudy Krutar, Bob Balzer, and innumerable operating 
systems* The idea is that the port acts as a channel through which 
commerce may be transacted with some processes exporting through it 
and others importing what the others export* The commerce is 
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completely containerized. An expression <CAL1 <|port| -values-» will 
place -values- in a container in lDort|, when a process iaports frou 
a port it will get one container of values to apply to a function. 
Eipty containers are allowed in which case the function of the 
importer will be passed no arguments. 

Another exaaple of the use of multiple processes occurs where 
there are two line printers and a number of processes which would like 
to get expressions printed. Suppose that <P0BT-T0-PBIHTBRS> is the 
port to which things to be printed are exported. Farter wore let 
<PHIHT-CHAHME1 1> and <PBIHT-CflAHHEL2> be the channels for printer 1 and 
printer2 restpectively. 

^^ <def ine printer 

*" * <f unction [print-channel] 

<repeat [ ] 

;"reaove the next eleaent 

frow the print-port. 



<call 

[] 

[ 



channel» 



print it 

on the print channel, 

and repeat * 



< function [x] 
<print 

.x 
•print* 

<port-to-printers>]»» 



<define setup- printers < function [ ] 



« process printer> 

; "create a process for driving 

the first printer and pass it 
its print channel" 
<print-channel 1» 

/"N <call 
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«process printer> 

<print-chaane!2» 

After <setup-printers> has been called, then «port-to~ 
printers> |xj> will cause Jx| to be queued and printed in its turn by 
one of the printers. 

How we would like to show how to do fringe? using ports 
instead of res uses. 

<define fringe? 

<f unction out [x y] 
<prog 

[[port-x <port>] 
[port-y <port>] 

[P* 

<process [tree- walk .port-x]> 

; "create a process which begins execution 

hanging on .port-x 

with the function tree-walk*] 

;*at this point an activation of *px is waiting 

in •pcrt-x* 

[py <process [tree-walk *port-y]>3 

;"at this point an activation of .py is waiting 

in .port-y*] 

<call 

<.port-x .x .port-x> 

; "export .x .port-x to 

the port .port-x" 

[ . port-x ] 

;"wait for a container of values 

from .port-x w > 

;"at this point an activation of 

.px is waiting 

in •port-x* 

<call <*port-y .y .port-y> [•poxt-y]> 

;"at this point an activation 

of .py is waiting 

in .port-y" 

<repeat [temporary ] 

<cond 

j< : temporary 
<call 

<.port~x> 
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[ .port-x]» 
;"the I allows the *no 
arguaents of ==? to be coaputed is parallel and thus allows th« 
processes .pi and .py to run is parallel to find the next atois in .x 
and . y" 

<call 

<*port-y> 

; "export 

an eapty container 

to .port-y" 
[.port-y] 

;"wait for a container 
on .poj:t-y"» 
<cond 

[<is? .temporary () > 
<.cut -i"true">]>] 
[-••else" <.out <»]>»» 

<define tree-walk 

<f unction [x p] 

<call 

<.p> 

; "export an espty container of values 

to the port .p" 

^\ [•Pi 

j "wait for a container of values 
on the port p"> 
<tree-walk1 .x . p> 
; "after doing the complete tree walk 

export () on the port .p" 
<call 

<-P ()> 

; "insert () in the port .p" 

E-P] 

;"wait for a container of values in 
the port .p">» 

<define tree-walk 1 

<f unction [x p] 

<cond 

[<eapty? .x> 

;"if the structure is 

eapty then return 
and try to find another atoa"] 
[<is? !=atoi .x> 

; "resume the main process with the 

a to a we have found" 
<call 

<.p .x> 
^ ; "insert .x in the port •?" 
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^wait for a container 
of Tallies 
in the port .p">] 
[ -* H else" 

< tree- walk 1 <1 .x» 

;«fiad the a tons in the first 

eleaent of .x" 
<tree-valkt <rest .x» 
;"find the atoas in the rest of 
•i and then 

return to finding ateas on 
the remaining branches* ]»> 



<IAIT-CILi 

<I pi -sead-args-> |f unction) > is exactly like CAit 
except that it is trilling to nait until J p| becomes resuaeable. 

l< IP I -args-> sight create a new process in which to evaluate 
<IPl -args-> in parallel with the noraal order evaluation of the 
original process. The first | in the previous sentence is not 
aeta linguistic. For example <* | <f oo 3 4> <bar 3 5> |o .x 7> <g 2 
2» initiates evaluation of <foo 3 4> and possibly in parallel 
evaluates <bar 3 5>. After <bar 3 5> has been evaluated, it initiates 
evaluation of <♦ .x 7> and possibly in parallel evaluates <g 2 2>. 
When all of the values have been computed, the function * is entered. 

M<IP! -args-> is exactly like J<|p| -args-> except that if 
one branch becoais blocked tne other is guaranteed to be able to try 
to continue execution. 



<prog f oo [ ] 



!l<stop> 
<.foc 1> 
;*exit .foo with 3"» evaluates to 3 
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<FCBK 

< 1 p I -args->> resumes execution of the suspended 
process lp| from the point that control last left it with the 
arguments -args- and in parallel continue execution of the calling 
process* It is an abbreviation for 

<CAL1 < 1 pj -args-> [ ]> 

For example <fork «prccess foo> <bar> a» causes <foo <bar> a> to be 
executed in a new process in parallel with the calling process* The 
value of the function FORK is \p\. The list of runnable processes is 
kept in the global value of the identifier BUNS&BIEI-SCHEDOLEH* The 
initial scheduler is driven by the following handler for BUHTIHE 
^^ interrupts when a certain amount of runtime has elapsed: 

!*<block {<oblist scheduler!-> <oblist>) > 

<f unction [ ] <prog twiddle 

[victea [V*giobal" runnable deserving]] 

; w the processes that are still deserving to 

be run are kept in 

the identifier • deserving 1 " 

<lccker [ ] <getc lock schedule-gueue> 

;"lock the schedule variables while 

they are being changed" 

<cond 

[ <empty? .deserving> 

<_ : deserving . runnable> 

<again • twiddle> ]> 

<_ (:victem ! .deserving) # deserving> 

<cond 

[<is? 

<getc Vstatus" •victea> 

^ f, runnable w > 

; w if the status is 

runnable then 

change it to running" 

/-v <putc 



v«running" ']> ] 
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.victem 
[^"status* 

[^"else" 

<again .twiddle>]> 
; w this scheduler is strictly first in 

first out" 
<continue • victem> 

<locker £ ] <getc lock schedule-gueue> 
<putc 

• victeia 

[status -• ?, runnable ,, ]>»» 

!%<end-block> 
<TEBHINAT£ 

- processes- > causes -processes- to be stopped, their 
stacks unwound # their timers and alarms to be unset, and then put into 
a state such that they cannot later be resumed, interrupted, or 
continued, A process is automatically terminated when it returns or 
fails to its top level* 
<STOP 

I p 1 > stops the process Jp| in such a way that it can 
later be continued or interrupted* 
<CONTINUB 

J p | > causes the process ] p J to continue execution from 
where it was stopped • 
<SUSPBSD 

J junction- name | |function|> suspends execution of the 
process which calls it. It is an abbreviation for 

<CAJLI J junction- name | [ ] J function J>« 
If the process is later resumed it begins execution by applying 
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{function) to the arguments received* 
<I8TEBBUPT 

1 junction- name | |p| <If| -arguaents-> |gj> will 
interrupt the process |pj to evaluate the function |fj applied to - 
arguments- IN THE PEOCESS |pl* If J f J returns normally then its 
values are given as arguments to lg|. Otherwise Jgj will be applied 
to the arguments with which it is resumed. The primitive INTERRUPT 
allows the definition of functions which are not HCNOTCHE in the sense 
of lattice theory. 



4.5* 1.2 Data Functions 
4.5. 1.2. 1 Specialists 



4.5.1.2.1.1 Structure Functions 



<STRUCTOBB? 

|xl> is true only if ]x| is of storage type vector, 
list, stack, ring, or node. 

<define structure? 

<f unction [x ] 

<rule [ ] <storage .x> 
[< either 
vector 
list 
stack 
ring 
^^ node> 



•"else" 
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<EHPTY? 

|x | > is true only if J x| is an empty structure, 

<define empty? 

<f unction [x] 
<and? 

<structure? .x> 

<"? <length .x> 0»» 



<H0NAD? 

\x\> is true only if ]x| is not decomposable. In 
other words JxJ is net a structure or it is empty* 

<define monad? 

<f unction [x] 
<or? 

<not? <structure? .x» 
<eopty? .x»» 

<CLGSUBE 

| procedure J Jfree-variailes|> returns the closure of 
the jprocedurej with the free variables bound to their values at the 
time when the closure is constructed* The CLOSURE primitive allows 
procedures to to have cwn variables. They enable us to easily 
construct generators such as those of GPS. 

The function twice will take a function f as an argument and return a 
function which applies f to its arguient twice. 

<define twice <f unction 



twice <f unction Tf ] 

<closure <f unction [x] <.f <.f .x>» f»> 
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«prog [x 3] 

« closure <function [] .*> x»» evaluates to 

<prog [a [b 1]J 

<_ :a <closure <f unction [ ] .b> b» 

<_ :b 2> 

<*a» evaluates to 1 

<proq [x **J 
<prog [ 

I j <clo$ure <f unction [3 ^x> x>] 
[* 0]] 
<.y»> evaluates to 4 

Suppose that *e wanted to define a generator Jfj to be 
<eleaents lxj> such that each tiae that <|f|> is evaluated it returns 
a new element of |x]« 

<define elements <f unction [x] 
<closure 
jm^ <f unction [ ] 

<prog [[next <1 *x>]] 
<chop x> 
• next» 
x»> 

How if we evaluate: 

<prog £C| p <flf|»t f> (a b c>> 3 ] 

;"a is printed" 

<print <.f» 

• "b is priated"> 

<BES1 

Jxl In | ♦oot-£oand*> returns the result of taking the 

rest of jx] Jnj tines. If the rest of |x| cannot he taken |n| tines 

then ♦not- found* is evaluated. 

<rest [a U f ] 2> evaluates to (d f ] 
<1 <rest <node £1 a] [2 b]>» is b 
<rest <rest (a 4 d f ] 2> -1> is [4 d f] 



4.5 page 132 

If Jul is positive then, <rest <rest | x] Jn|> <- |n|» is an error or 
is identical to |x|. the function BEST with a negative ]n} aay be 
applied only to tuple pointers, vector pointers, and node pointers* 
it aay not be applied to list pointers. 
<GET 

(indicator] lobjectj ♦not-found*> returns the value 
under lindicatorl for the ]object| if such exists. Otherwise it 
returns the value of nct-^found. Integer indicators have special 
properties so that structures can be nade out of lists, vectors, and 
nodes alaost interchangeably. The expression <) integer] {object! 
♦not-foundO is an abbreviation for <GET (integer) lobjectj *not- 
found*>« 

<3 (a b c) > evaluates to c 

<-1 <rest [abed] 3» is b 

<2 <rest <node [foo 1] [3 a] [2 b]>» is a 

<2 [a (b c) d]> evaluates to (be). 

<get feo 

<node [foo 1] [*» a]» evaluates to 1 

<GET!-HO-acnitor 

lindicatorl J object! ♦ not- found* > is exactly like get 
except that bo ni tors for the location under (object) with arc naae 
lindicatorl will not be triggered. 
<W AIT-GET 

lindicatorl lobjectJ> is like GET except that if 
lobjectj does sot yet have anything under lindicatorl then the process 
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is suspended until | object J has soaething PUT under I indicator). 
<AT 

Jil Jo J ♦not-foundO returns the location of the value 
under the indicator JiJ of the object foj. 

<putloc <at 2 [a ft ]> 8> evaluates to [a 8] 
<AT |o|> is the locative to the value of the identifer I o| if 
Jo | is an atoa and a locative to the rest of |o| if |o| is a list. 
<ABC 

|o] linaicatorj ♦ not-foundO is the arc froa the 
object ]o| with aaae J indicator I if there is one. Other vise ♦not- 
found* is evaluated. 
<IBITI1L 
^ s - Jo J ♦not-fouadO is the initial node arc for the 

object joj if it has one. other vise it returns the value of ♦not- 
found*. 

<HEXT 

Jxj ♦nct-foundO returns the next arc after I x J for 
the object |oj, if there is one. Otherwise it returns the value of 
♦not-found ♦. 

<EIO? |o|> is true only if |o| is an end node vith no leaves 
leaving it. 

<laST? 

Jzj> is true only if jx| is the last arc of the node. 
<ISDIC1T0H 

Jx|> is the indicator for the arc |i|. 
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<indicator <initial <node [a 3] [4 "r" ]»> is a 

<HEAD 

1xl> is the object at the head of the arc |x|. 

<head <arc <put 3 [larger 2] [smaller 4]> smaller» is 
3 

<TAI1 

| jc i> is the object at the tail of the arc |xj. 

<tail <arc <node [a 3] [4 »t» ]> a>> is 3 
<L0CA1IVE 

jx |> is the location which holds the object at the end 

of the arc | x] . 
<COPY 

JxJ> will conpletely copy |x|. 

Jxl J y | > is true only if |x| and |y| are identically 
the same object. 

<=? 

Ul lyl> is true only if jxj and |y| print the sane as 

structures. 

<define =? <f unction egual [x y] 
<egual1 .x .y .egual»> 

<define egual 1 <f unction egual 1 [x y egual] 
<cond 

[<or? <nonadic? .x> <«onadic? .y» 
<cond 

[<==? .x ,y> 
-•"true" ] 
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[-•"else" 

<. equal <»]>] 
[<*=? <type ,x> <type ,y» 
<repeat [ } 

<cond 

[<e«pty? ,x> 
<cond 

£<eipty? .y> 

<.egual1 -."true">] 
[-»* , else H 

<.equal <»]>] 
[Xeapty? ,y> 

<. equal <»]> 
<prog out [ } 

<egual1 

<1 

• x 
<cond 

[<has? 1 .y> 

<. equal <» ] 
[-•"else" 

<.out>]» 

<1 

/^ <. equal <»> 

.equal» 
<chop x> 
<chop y>>] 
[-•"else" 

<. equal <»]>» 

<SIHILAB? 

I*l J7l> is true only if |x{ and |y| have similar 
values under their respective positive indicators. For exaaple (3 
"a4" [i"a]) is siailar to [3 (!"a !»«») "a"]. 

<define siailar? <f unction sis [x yj 
<sinlar1 .x .y .sii>» 

<define similar 1 <f unction sial [x y sial 
<cond l * *»*-j 

[<or? <aonadic? .x> <aonadic? ,y» 
<cond 

[<*? .x .y> 

-»*tr«e"J 
^~ [-»"else" 
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K.sim <»]>] 

<repeat [ ] 

<cond 

[<eapty? *x> 
<cond 

[<eapty? *y> 

<„sim1 -* w true*>3 
[-•"else" 

K.sim <»}>] 
[<eapty? .y> 

K.sim <»]> 
<prog oat [ ] 

<sisilar1 
<1 

<cond 

£<has? 1 ,y> 

K.sim <»J 
["•"else 11 

K.ont> p> 



<chop x> 
<chop y»]>» 



<1 

• sim» 



•y 

K.sim <>» 



<ISOHOBPHIC? 

|z-| lyl> is true onlj if |x§ and }y[ are isomorphic as 
graphs* 

< define isoaorphic? <f unction iso [x y] 

<iso 1 • * . y • iso>>> 

<define isol <£ unction [x y iso] 
<cond 

[<«? <type • *> <type .y» 
<prog out [ ] 
<sab-iso1 

<initial 
• x 

<,out> 

;«if . x has ao arcs then exit 
•qut*> 

.iso» 
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if"*^. 



/■"■n 



<prog cut [ ] 
<sub-iso1 

<iiiitxal 

•y 

<.cut» 

• iso» 

-^true" ] 
[^"else" 

<«isd <»]>» 

<define sub-isol <f auction sub-iso-n fx-arc y iso 1 
<repeat [ ] J 

<iso1 

<tail .x-arc> 

<get <inaicator *x-arc> 

•y 



<.iso <» 

;"£ .y does not have a arc with 
<indicator .x-arc> then, 
exit •iso with <>"> 

• iso> 

•x-arc 
<next 

•x-arc 

<.sub-iso-n> 

;"exit .sub-iso-n if there are no 
aore x-arcs f, »>» 

<PUT!-PEBSISTB8T 

J object l -proper ties-> puts the properties on the 
JobjectJ. A property of the fora [jindicatcrj |v|] puts the value 
|v| under the J indicator |. i property of the fora [ J indicator 1 ] 
deletes the | indicator J frca the object. Integer indicators have 
special properties so that structures caa be aade out of lists, 
vectors, and nodes alaost interchangeably. 

<put <node (a 4] £3.5 c]> [a b] [3.5] ££ej 9]> 
evaluates to #node [[a b] ££e] 9]] 

<put (a 4) £1 «c«3> evaluates to ( m c m 4) 



/» 0m \ i 
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Properties can be put on A HI of the data types of HATCHLESS. For 
example <put 3 [size small ]> puts the value suall under the indicator 
size for the fixed point number 3* The ability to associate any piece 
of data with any othet piece is very useful. For example Gerry 
Sussman has pointed out that comments can be implemented in this way. 
The degree to which an expression has been simplified can be recorded. 
For example we might <put •<♦ 3 4> [simplified canonically ]> to 
indicate that *<* 3 4> has been simplified canonically. 
<PUT!-TEHTATIVE 

|object| - properties- > is exactly like POT except that 
the properties of lobjectj are restored on backtracking. 
<P0T!-H0-H0NITOR 

lobjectj -proper ties-> is exactly like P0T1-PBBSITENT 
except that the monitors for the locations are not triggered. 
<PBTBEST!~PERSISTEMT 

jx | |y| |n l *not-found*> changes the BEST of the list 
<rest Ixl |nl> to be Jyl where JyJ must be a list. If <rest )x] <♦ 
in I 1>> is not a list then ♦net-found* is evaluated. 

<putrest (3 a) (fl 5) > evaluates to (3 <» 5) 
<P0TBEST '-TENTATIVE 

}x I JyJ l n | ♦nct-foundO is exactly like PDTBEST 
except that \x\ is restored on backtracking. 

<define putrest I -tentative <f unction 
[x -i" optional* 

[y 3 
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^\ 

[n 0] 

[ not-found ! f <error> ] ] 
<failpoint [[save <rest . x .n>]] 

<putrest .x .y .n .not-found> 

[-•"optional 11 ] 

<putrest .x .save .n>>>> 

<CHOP!-PERSISTENT 

|x| jn] +not-found+> assigns the identifier |x| the 

rest taken |n| times of its current value. The function CHOP was 

invented for a variant of LISP at MITBE. 

!X<block (<oblist chop!-> <oblist>)> 
<define chop 

<f unction 
[ f x 

-•"optional" 
[n 1] 

[ »not-f cund f <error>]] 
< 
f ^ ~ :.x 

<rest 

• .x 

• n 

• nct-found»» 
!X<end-block> 

<prog [[y (1 2) ]] 

<chop v>> evaluates to (2) 

<CHOP!-TENTaiIVE 

|x| ln| ♦not-founao is like CHOP except that its 
results are not undone on backtracking. 

!X<block {<oblist chcp!-> <obiist>)> 
<define chop 

<f unction 
['x 

-•"optional" 

[n 1] 

[ f not-found f <error>]] 

<_ _•» <rest ..x .n . not-found»» 
j*—^ !%<end-block> 
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<LENGTH 

jxj> returns the length of the value of |x | . 

<length (a b c)> evaluates to 3 

<define length <f unction In £z] 
<for [[n 0]] 

[[-."in" <?> .x3 
[-."final" <.ln .n> 

;"exit .In with .n"3 
<inc n>3>» 

<INDEX 

|x|> returns the rest index of Jxj. The function 
INDEX is only defined for vectors and nodes. 

Xindex <rest <rest [a e !»e e f g] 2> 3» is 5 

<TCP 

ix J |nf ♦not-found*> is <BEST \x\ <- *n| <IHDEX |xj» 

♦not-found*> 

<BOTTOH 

|x| |n| *not-found*> is <HEST U| <- <iBHGTB |x|> In|> 

♦not-found*> 

<UNIQUIZE 

I value ]> returns a pointer to the unigue copy of 
lvalue). The function OHIQDIZB can be used to save space and tiae in 
computations. The expression <0HIQUIZE | value |> lay be abbreviated as 
!-*|va3.ue|. The function OHIQOIZE is doe to Peter Bishop. 
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/"""v. 



<uniguize "efg"> is ^"efg" 

<uniguize (a !"b ("e" 3])> is -»(a l n b -»[^»»e" 3]) 

<prog ££x = £a be]]] 

<uniguize ,x> 

<uniguize <copy .x»>> is true. 

<OHIQOEtI? 

|xj> is true only if |x| is a uniguely created copy of 

|x| i.e. to be <==? Jx| <DHIQDIZB |xj». 

<INCBE*SIHG? 

-elements- > is true only if -elements- are arranged in 

increasing order in the the total ordering on unigue expressions. 

< SUBSTITUTE 

f~^ Jx| | pattern | Jz|> substitute the value of |x] for all 

expressions in ]z| that aatch J pattern |. 

Substitute a !=atoa (1 {x z) ) > evaluates to (a (a a)) 

!%<block {<oblist substitute !-> <oblist>)> 

<def ine substitute <function 

£x «p z] 

<subst 

<eval !»<actor [] .p» 

< define subst <f unction [i p i] 
<rule £ ] .z 

£<.p> 

•X] 
[<»onadic> 

.*] 
£<linear {!}> 

«type .z> 

<subst .x .p <1 .«» 
^^ {subst .x .p <rest .z>}>] 
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[<?> 

.Z ]»> 

!5t<end-block> 
<BEKBEE? 

|pat| JstrucJ> is the tail of Istrucj whose first 
element matches lpat| if there is one and otherwise is <>. 



c] 



<raember? !-atom [3 4.5 <a) b 6 c]> evaluates to [b 6 



IlUblcck (<cblist member?> <cblist>)> 

<define member? 

<f unction [ f p s ] 

<member1 

<eval ! f <actor [] .p» 

• s»> 

<define memberl 

<function out [p s] 

<repeat £ ] 

<cond 

[<is <empty> .s> 

<.out <»] 

[<is <.p> <1 .s» 

<.cut .s>]> 

<chop s>»> 

!*<endblock> 



4.5, 1.2. 1. 1. 1 list 



<1IST!-CONSTBUCTOR 

-values-> constructs a list of -values-. It is 
eguivalent to (-values-). 



/***% 



/""N 
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4,5. 1.2. 1.1.2 Vector 

Any expression enclosed within " {" and *) " evaluates to a 
list. Any expression enclosed within »[" and w ]" evaluates to a 
vector* 

<IVECTOB 

|n J Jfcn|> creates an implicit vector of length the 
value of in | with entry i initialized to <Jfcn| i>. 



<define i vector <product vector vector [n fl 
[[i <thru 1 .n>] [<.f .i>]]» J 

<i vector 
3 

<f unction [i] .i» 

evaluates to [ 1 2 3]. 
<ITUPLE 

|n| Jfcn|> creates a definite tuple of length the 
value of ]n| with entry i initialized to <jfcnj i>„ a definite tuple 
can only be created as the initial value of an identifier in a 
declaration, as an element of a definite tuple, or as an argument to a 
function. 

<ISDEMHITE 

type [-declarations- ] 

[ -f or-specif ications- 
[-'"EXIT* |out-name|] 
£-*"ADJCIH* J expression) ]] 
-body-> 
creates an indefinite tuple by setting up a for loop in which the 

elements of the tuple are generated element by element such that 
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condition is met. An indefinite tuple can only be created as the 
initial value of an identifier in a declaration as an element of a 
definite tuple, or as an argument to a function* An indefininte tuple 
is a good nay to pass arguments which are generated incrementally at 
run time* Ho tuples may be declared in -declarations-* Evaluating 
<* jout-name|> will cause IHDBFIHITE to return *ith the tuple 
generated* 



a.aefi-tt* [ti-M«[ii]]] 

;* declare i to be a fixed point 
number initialized to 1* 
[[-"inc" i -."thru* *n] 
; w increment i thru •n" 
[-•"adjoin* *i] 
;"each time through the loop adjoin the value 

of i to the tuple" ] 
; w the body o^ the loop is empty M > 



evaluates to 



[1 2 3 4] if the identifier n has the value 4 



<UNSHABE 



|x l |tail-of-x|> creates a copy of the value of |x| at 
the top level* The value of |tail-of-xI must be obtainable from the 
value of lxj by repeatedly applying the function BEST. The value of 
the function UNSHABE is egual to its argument but it is not identical* 

<unshare £ 1 x (y 2.0) ]> evaluates to [1 x (y 2*0)] 
<prog ££!=vector £x £a {^)J3]] 

<is? <» <2 *x» <2 <unshare *x»» evaluates 
to true* 

<V EC TO H I -COH STB0CTOB 
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- values- > constructs a vector of -values-* It is 
equivalent to £-values-j. 

4.5. 1.2* 1.1*3 String 

<S1BIHG ! -CCMSTBnCTOB 

-values- > constructs a string of the -values-* 

<string 

"Bun* 1 

n it 

"Dick" 
it it 

"run" 
evaluates to "Bun Dick run*" 

4.5. 1.2* 1* 1*4 Graph 
/"> <BCDE!-CCHSTBUCTOB 

-properties-> constructs a node with -properties-. 
<SHABE 

1 node l J indicator J 1 locative J > will cause |node{ to 
share the location under ] indicator! with the location Ilocatiwef. 
The function SHABB is due to Peter Bishop* 
4.5.1.2.1.1*5 Class 

<CLASS I-COHSIBUCTOB 

-elements- > will construct a class with -elements-. 

4*5*1.3*1*2 Atom 
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<ATOM!-C0NSTB0CTOR 1 string J> is the atom on the root cblist 

with print name Jstringl. 
<ATOH!-C0NSTB0CTOR 

Jstringl J path | ♦not-found*^ is the atom with the 
print name jstringl in the Ipathj of oblists. If the optional 
argument ♦ not-found* is not present and there is not atom on (path) 
with print name Jstringl then a new atcm is created in <1 |path|>. 
<PNAME 

jatom|> is the print name of Jatomj which is a uninque 
string. 

<pname hello!-dolly!-> is vhello" 

4.5. 1.2* 1*3 lord and Rusher Functions 

<BITS 

|s | I p | > defines a field of \s\ bits that is |p| bits 
from the right end of the word. 
<SIGSED-BITS 

|s J | p | > defines a signed field of Jsj bits that is 
| p| bits from the right end of the word. 
<B*TE 

|s | ]p I |e|> returns a byte pointer to the byte of Js| 
bits that is |p| bits from the right end of the word pointed to by 

|e|. 

<IHC!-SEBSISTENT 
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Ivarj Jdelta|> increments the value of the identifier 
Ivarl by |delta| and stcre the result in JvarJ. The body of INC will 
be put in a separate lexical block so that ilentifier collisions 
cannot occur. 

!%<block (<oblist inc!-> <oblist>) > 
<aefine inc <f unction [*x] 
<_ :.x <♦ ,.x 1>»> 

!%<end-block> 

<INC!-TENTATIVI 

ivarl J delta | > is like EEC except that |var| is 
restored in backtracting. 

!X<block (<oblist inc!-> <oblist>) > 
<define inc! -tentative <function [»x] 
< .x <♦ ..x 1»» 

!X<end-block> 

<DEC!-EERSISTENT 

|var| |delta|> decrements the value of the identifier 
Ivarl by |delta| and store the result in Jvarj. 

!X<block (<oblist decl-> <oblist>)> 
<define dec <f unction £»x] 

<_ : .x <- ..x 1»» 
!X<end-block> 

<DEC!-TENTATIVE 

Ivarl |delta|> is like DEC except that lvar| is 
restored in backtracting. 

!X<blcck (<oblist dec!-> <oblist>) > 
<define dec! -tentative <function £'x] 
< .x <- ,.x 1»» 
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!*<end-block> 

<ASCEBDIHG? 

-elements- > is true only if -elements- ar0 in 
ascending order. The function ASCBHDIHG? is aue to Gordon Benedict. 

<define ascending? < function out [^"rest" x] 
<cond 

[<is? <empty> .x> 

<.out ^• , true w >] 
[ *else* 

<repeat [ ] 

<cond 

[<is? <empty> <re^t .x» 

<.out ^ l, trae ,l >] 
[<not? <is? 

< greater <1 .*» 
<2 .x>» 
<.out <»]> 
<chop x»]>» 

<DESCE»DING? 

-elements- > is true only if -elements- are in 
descending order. 
<IDIVIDE 

fdividendl -4ivisors-> computes the | quotient | and 
I remainder} of the | dividend I divided by the -divisors-. 

[a ! {idiviae 7 31! 69] evaluates to [a 2 1 69] 

<call 

<iaivide 1 1 4> 

^function [g r ] 

<print .q> 

<print .r>» 

;" prints 2 and then prints 3 H 

<♦ 

-numbers- > is tke sum of -numbers-. 



/~\ 



<* 



<ABS 



<EXPT 



<- 



/"""" N (tractors-. 
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<♦ 3 4 -5> is 2 

-numbers- > is the product of -nuabers-. 
<* 5 6> is 30 

|a]> is the absolute value of |n|. 
<abs -3> is 3 

J base | | exponent | > is exponentiation. 
<expt 2 3> is 8 

(subtrahend i -subtractors-> is |subtrahnd| less - 



<- 3 2> is 1 
<- -5> is 5 
<- 3 9> is -6 
</ 

(dividend I -divisors-> is the floating point nuiber 
( dividend ( divided by -divisors-. 

</ 4> is .5 
</ 12 3> is 4.0 
</ 3 2> is 1.5 
</ 30 2 5> is 3.0 



r\ 
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<flAX 

-values- > is the aaxiaua of -values-. 
<aax -3 <♦ 4 .1> 4> is 4.1 

<HI* 

-values- > is the ainiaua of -values-. 



4.5. 1.2. 1.4 Algebraic 



<!♦ 



-teras-> constructs the sua of the teras. 

<!♦ 

«<* <expt x 2> 3> 

3 

•<* 2 x> 

•<* 4 x> 

4 

•<expt x 2» evaluates to 



<♦ 



<!* 



7 

<♦ 6 x> 

<* 4 <expt x 2>» 



-factors-> constructs the product of the factors. 

<!* 3 <!♦ x 2> <!♦ x -2> x> evaluates to 
<♦ 

<* 3 <expt x 3» 

<* -12 x» 
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4.5.1.2.1.5 Locative 



<I8 

Jlocationj> returns the contents of J location) as its 
value. 

<prog [[x 1]J <in <at x>» evalutates tc 1 

<GENLCC 

Jxj> generates a new location (which is not on the 
stack) holding the location of jx|. 

<in <genloc 3» evaluates to 3 
<PUTLOC!-PBHSISTEHT 

(location | J value |> stores the J value | in the 
/•*\ llocationj and return the | value |. it is equivalent to <_ <s»ash 
]location|> |value|>. 

<prog [x] <putloc <at x> 1» assigns x the value 1 
<PUTLOC! -TENTATIVE 

1 location | lvalue | > is exactly like POTLCC except that 
|location| is restored on backtracking. 

<de£ine putloc!- tentative <function [location value! 
<failpoint 

[[save <in .location>]] 

<putloc .location *value> 

[-.•optional"] 

<putloc .location •save»» 

<?ALUE 

|theta| J bindings )> is the value of the identifier 
-^ which is the value of Jthetaf. 
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<prog [[-^special" [x 111 [v •«!] 
r <value .y» evaluates to 1 



4.5.1.2.1.$ Stack 

Stacks obey a last in first out storage discipline. 
<stack 

♦checker ♦> returns the naae of a newly created stack 
to store elements of the appropriate ♦checker*. 
<P0SH 

)stack| -values- > pushs the -values- onto the | stack). 
The value of POSB is J stack |. 
<POP 

lstack| |nu»ber| ♦not-foundO pops I number | elements 
off (stack )• and returns then as the values of POP. The elements 
come off in the opposite order they nent on. 

(1 !(pop 

<push <stack> a b c d> 

el}) evaluates to (1 deb). 

4.5. 1.2.1.7 Bing 

Elaents can be inserted and removed from either end of a ring. 

<BIHG 

♦checkerO returns the name of a nenly created ring to 
store elements of the appropriate type. 

<FBOHT 
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Jringl J number | ♦not-found-o returns the front 
(number) elements of iringj. 
<B1AB 

J ring J | number | +not-fouud»> returns the rear | number | 
elments of Jringl. 

<INSEBT-FBOHT 

Jringl -values- > inserts -values- into the front of 
Jringj. 

<IHSEB1-BEAB 

Jringl -values> inserts -values- in the rear of 
Iringj. 

<DELBTE-FBCNT 
/O Jringj J number J +not-fo«nd*> deletes J number J elements 

from the front of Jringj and returns them. 

[a ! {delete-f ront <insert-rear <ring> 1 2 3> 2!) b] is 
[a 1 2 b] J 

fa 3 2 bl ^ a ! t delete ~ rear <insert-rear <ring> 1 2 3> 2!} bj is 

<DELETE-BEAB 

Jringj ] number J ♦not-found* > deletes (number | elements 
from the rear of I ring] and returns them. 

4.5.1.2.1.8 Character 
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<CHABACTEB> 

Batches any character. 

<LOIEB> 
latches an; of the twenty six lover case alphabetic characters* 

<OPPEB> 
aatches any of the tunety six upper case alphabetic characters. 

<DIGIT> 
■atcbes any character which is a digit. 

<AXPHABETIC> 
Batches any alphabetic character. 

<define alphabetic 
<actor [ j 

<either <lower> <upper»» 

4.5.1.2.1.8 Input-output 

In put- output is transacted through channels. The atonic aaaes 
read in are looked up in directories called ob lists. 
<CHAHHBL 

ldirectionj | placet } place-dependent |> returns a 
coBBunication channel in the | direction | specified to the (placet 
naned. The ) direction | Bay be either -*"BEAE" or -•"PBIIT". 
<CIOSB 

-channels-> tertinates transactions on the naned - 
channels-. 



r\ 
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<BESET 

-channel-> resets (channel]. 
<PBINC 

Js| jchannels|> prints |s| (which aust be a string or 
charater) literally. It does not put guotes around it or otherwise 
translate js|. 
<PfiIH1 

J xj [-channels-] j path J 1 print-table} i aacro- table |> 
prints the value of |x| on the output channels relative to Ipathl and 
returns it as the value of the function PRINT. The various types are 
printed according to the print functions which are defined in | print- 
table |. The function PBIHT aaintains three special identifiers: 
^ PATHI-PBIHT, TAELEI-PB3MT, M*CBOS!-PBIIT, and CHIIIEIS! -PBIHT. The 
J print-table J last be a TYPI-YECTOB. The |aacro-table| aust be a 
CHABACTEB-VECTOB which has entries -»"HE?EB", -»"BEGHIHG", or 
-•"AL1AIS". 

!%<block (<oblist print!-> <oblist>)> 
<define print 

<f unction [x -^"optional" 

[-•"special" [channels .channels]] 
[-•"special" [path .path]] 
[-•"special" [table .table]] 
[-•"special" [aacros .aacros]]] 

«getc <type .x> .table> .*>» 
!%<en<?-block> 

The print function for vectors is: 

<f unction out [vl 
<cond J 

[<eapty? .y> 

<priac "[ ]«> 
j-S <.out .y>] 



4*5 page 156 



[•^"else* 

<princ !"[ 

; "print the open bracket which 
will be closed by ]*> 
<repeat [[x *y]] 

<prin1 <1 .x» 
<chop x> 
<cond 

[<eapty? .x> 
<princ 

; "close the [ * 
!"]> 
<.out *y>]> 
<princ ! " > 
; n print a space*>]» 



<PBINT 

1x| | path] 1 print- table | | channels |> prints a carriage 
return line feed, prints Jxj and then prints a space* The (print- 
tablej oust be a TIPE-¥ECTOK. 

<define print 

<f unction [x -*"optional* 

[^"special" [path .path]] 
[-"special* [table .table]] 
[^"special* [channels •channels]]] 
<princ * *> 
<prin1 .x> 
<princ * ">» 



<OBLISt> is the root cblist. 
<OBLIST 

1 trailer J *not-foand*> is the oblist with the 
specified ]trailer|. If the optional argument ♦not-found* is not 
present and there is no oblist with J trailer I then one is created. 
<THAILEH 

|ato*|> is the naae of the oblist on which |ato*> 
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exists. The trailer cf an a tea on the root oblist is <>. 

<0b 

|string| Jpath|> returns the first oblist in lpath| on 
which an atoa with prist name J string | exists if there is one. 
Otherwise it returns <>. 

<LIHK 

latoaj )path| Jstring|> creates link en the first 
element of | path J with print nane Jstring]. It is an error if there 
is an atoa with print cane (string! already on J path). Both I path | 
and Jstringl are optional. 

<prog [ ] 

<link 

top! -middle! -botto t 
/-\ (<oblist ae!->) 

«tmb"> 
tmb!-me> evaluates to top! -middle! -bottom 

<B10CK 

I path | > begins a new lexical block where atoms are 
looked up on |path|. fhe function BLOCK is due to Jerry Sussaan. 

<EBD-BIOCK> 
closes the current lexical block restoring PATHI-BE1D to its previous 
value. 

<BE1DCB 

} channel] ♦ not-found* > removes the next character from 
I channel). If there are none, then *nct-fouad+ is evaluated. 
<HEITCfl 

tchannelj *not-fouad*> is the next character is 
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J channelj. The channel is not modified by KBXTCH. If there are none 
then ♦not-found* is evaluated* 
<HEAO 

1 channel) ]path| ♦not-found* Jnacrcsl | syntax |> 
returns the next expression froa the input (channel] with atoas which 
are sot on 1 path J created in the first eleaent of Jpath|. The lacro 
characters are as defined by functions of one argument in Jaacros) 
which aust be of type VECT0B-OE-CHABACTEBS. The arguaent of the 
function is the aacro character which triggered it. The lexical 
syntactic class of each character is defined by {syntax} which also 
■ust be a CHABACTEB-VECTOB. The idea for the read tables is due to 
John ihite If there are no acre expressions on the channel, then ♦not- 
found* is evaluated. The function READ maintains special local 
identifiers CHAHHELI-BEAD, PATHI-BEAD, HCT-FCUHDI-BEAD, HACBOSI-BEAD, 
and SIHTAX1-BEAD. froa which it obtains the appropriate information. 
The definition of BEAD is: 

!%<block (<oblist read!-> <oblist>) > 

<define read 

<f unction [^"optional" 

J>"special* [channel .channel]] 

{-•"special* [path •path]] 

[-•"special" 

[ • not- found 

•<error ^"end-?of~file- 

reached">]] 

[Especial* [table .table]] 

[^"special" [syntax .syntax]]] 

< prog loop [character] 

<_ : character <nextch» 

;"let character be next charaacter 

about 

to be read" 



^*"\ 



^"ignore 1 ^ 



associated 
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<cond 

[<is? <getc •character «syntax> 

<again *loop>]> 
«getc <readch> . table> *character» 
; "execute the read procedure 



with the first character"» 

!%<end-block> 
The following are the lacro characters which are predefined for the 
reader: 

# I type | Jobject) reads J object! then tries to 

convert it to be a I type |. 

For exaaple tconplex [3 4] will attempt to convert [3 4 ] to 

type complex • 

!#FALS£ is the unigue object FALSE. 

_. !#NODE ♦ rest-index* [•properties-] where each 

f^ Ipropertyl is of the fora [! indicator] (value)] is a node* 

!#PROPEBTIES Jobject | [-properties-] where each 
ipropertyl is of the for* [| indicator) lvalue)] 

is an object with properties. 

If ABC [Jobiectj | indicator |] is a arc fron Jobject J 
with nane [indicator )• 

!1 character) is read as a single character* 
The I serves as an escape for characters 
which cannot b* input directly* 

11^ is. the exclamation character. 

Thxs xs the only way to get in the character ! • 

Xjfora] .reads Iforn) evaluate it and use the value as the 
expression read* 

The % aacro is doe to Chris Beeve. 

!X)fornl reads Iforn| evaluate it and then pretend that 
what was actually read was the null string* 
The 1% macro is due to Chris Beeve* 

The wacro character IX enables us to have side efxects while 
reading* 
^0**^ For exaaple: 
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!%<block ]path|> causes the reader to read the 
subsequent 

iteas into lpath| until the latching !*<end-block> is 
encountered* 

$ terminates ccaaands* 

" J string | " is a character string* 

I 11 1 character I is a single character. 

* J character] reads J character | as though it 
were not a special character* 

In other words *|characterl is an ordinary 

alphabetic character to 

the literal reader as though <getc JcharacterJ Jsyntax|> were 

-"alphabet ic"* 

f-elenents-) is a list. 

The read function for !"( is: 

<function [cj 

;"tbe value will be a list* 

<list 

{indefinite [x] 

; "construct a tuple of indefinite size 

nade out of the values of x" 

[[-"adjoin" *x] 

[-"exit" out]] 

<call 

<read> 

<f unction [-"rest" t] 

<cond \^^ 

[<is? <length .t> 2> \ 

•"read has returned with 

two values" 

<rule [ ] <1 .t> 

[; "first of „t latches {" 

!") 

;"the first value is 

a right paren" 

<*put>] 

-."else" 

<error 

"lisiatched 

lef t"» ] 

[-"else" 

<_ :x <1 *t»]>»}» 
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The read function for !") is: 

<f auction out [cj 

;"exit with two values so that any 
function which 
calls this one will know 
something is fishy" 
<.out 

;"this should latch (" 

!») 

<>» 

[-elements-] is a vector* 

!T -elements- ! ] is a homogeneous vector* 

The notation Is due to Chris Beeve and Gerry Sussman. 

<-elements-> is an element fori. 

{-elements-} is a segaent fora. 

! {-elements- !} is a aultiple value segaent fora. 

f~^ llforal is #ALI08-PA*ALLEL JfornJ. 

!Jlform| is iESSEHTIAL-PABALLBL |fora|. 

latoaj!- forces Jatomj to be read into the BOOT oblist. 

I a torn J !- 1 trailer |. reads iatoml into the oblist with Itrailerj. 
If the following is typed in: 

<prog [ ] 

foo! -thesis! - 

bar!-preface!-thesis!- 

!S<block (<oblist preface! -thesis !-> 

<oblist thesis!->)> 
(mumble hello!- foo bar 3 thesis preface) 
!*<end-block» 

then it will evaluate to 

(mumble! -preface! -thesis 

hello 

foo! -thesis 

bar! -preface! -thesis 

3 

thesis 

preface! -thesis) 
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{-expressions- |eieient| ; icoaoentj -aore-expressioas-) 
The read function for ! w ; is: 

<f unction out [character] <.out ! w ; <read>» 

(-expressions- ]eleaentl !; {intent | -Bore-expressions-) 
The read function for !"!; is: 

<f unction out [character] <*out !"!; <read>» 



The following prefix a aero characters are predefined. 



9 1 expression | is <QDOTB 1 expression !>• 

The 9 aacro is due to John White* 

The read function for the character 9 is: 

<f unction [character] ! 9 <guote <read>» 

! 9 JforaJ is <SOPPRESS |fora|> which suppresses invocation 

of | fori]. 

The read function for !"!• is : 

<f unction [character] ! f <suppress <read>» 

^jTaluel is a unique copy of J value! • 
The read function for !*-• is: 

<f unction [character] <uniquize <read»> 

!-*|valuel is <UHIQOIZE j value J>. 
The read function for !*!-* is: 

<f unction [character ] ! 9 <uniguixe <read>» 
!=|atoa| is <OP-TTPE |atoa|>. 
6 J fori J is <GATE }fora|> 

!t<-eleaents-> is <TEHfOHIM <-eie«ents-» 
!t {-eleaents-} is (TEBFOfilBY <-eleaents~>} 
!s<~eleaents-> is <S3RAIGHTB* <-eleaents-» 
Is {-elements-} is (STfiAIGBTEI <-eleaents->} 
!p<-eleaents-> is <PEE SIS TEST <-eleaents->> 
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/""S 



!p{-ele«ents-) is {PEBSISTBHT <-eleaents->} 
The macro characters ft Is, and !p are due 
to Peter Bishop. 

.1 identifier | is <VALUI Jidentif ier I >. 
!.i identifier J is {VALUE Jidentif ier J) . 
, JidentifierJ is <GLCBAI Jidentifier>. 
!, Jidentif ier | is {GLOBAL Jidentifier} . 
_J identifier J is <ALTER! -TENTATIVE Jidentifier J >. 
1_ Jidentifier | is (ALTER I -TENTATIVE JidentifierJ}. 
: JidentifierJ is <ALTEB!-PEBSISTENT Jidentifier J >. 
!: lidentifierj is {ALTEBI-PERSISTEHT JidentifierJ). 
? J identifier | is <GIVE8 J identifier J >. 
!? JidentifierJ is {GIVER JidentifierJ). 



/"^ 



4.5.1.2.2 Protection 

<UBPBCTECT 

Jx] Ju]> allows access to the object x according to 
the use Juj which may be: 

-•"write" for write 
-•"execute" for execute 

Bestricting the access of a piece of data ensures that it can not be 
used for a purpose which was not intended. Por exaaple it can be used 
to insure that checking routines do not acidify the data which they are 
supposed to inspect for errors. 
<PBOTECT 
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|x I ju l> restricts the uses to which |xl nay be put by 
not allowing tbe use ju| which lay be -."READ", -."POT", or -""WHITE. 
The use -»"PUT" protects against putting on non-nunerical indicators 
whereas -»"BBITE" protects the numerical indicators. 

<put 

<2 <protect (a (3 4)) -*"write"» 

( 1 a ]> causes a write protection error 

<rest <protect (a 2 b) -."write"» returns (2 b) with 
write protect 

<PBOTECTIOH 

|x 1> returns a vector of the protection aodes of 
access for ]x(. 

<protection <rest <protect (a 2 b) -»"write"»> is 
[-•"write ] 

4.5.1.2.3 Honitoring 

<HCHITOB 

HI |f | ]u]> aonitors the location 11 1 with the 
function Jf J for the use |u|. The use nay be a list of any of the 
following: 

-•"BEAD" for read 
-•"EIICBTB" for execute 
-»"1RIIE" for write 

If a process attempts to nsed a nonitored location then <f Hi |uj 
\x\> is evaluated. If a write operation is being attempted, then x is 
the value which is being stored. If a execute operation is being 
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completed for a functicn, then x is the tuple of values being 
returned. If an execute operation is being completed for an actor , 
then x is the object that was latched. Monitoring is implemented in a 
way that is logically eguivalent to creating a arc from the location 
ll| to the list of aonitors for the location |1| under the indicator 
MONITORS* Dave Reed invented the more efficient method that is 
actually used. Monitors are useful for implementing various kinds of 
procedural data* For example they are used to implement break points 
in the language. The following procedure Mill make a list (called 
history-of-x) of all the values that are stored into the special 
identifier x. 

<monitcr 
f m s x <at x> 

<function [1 u v] 

<_ :history-of-x (.v !.history-of-x) » 
^ w write f, > 

Hext we would like to describe how monitors can be used to 
implement an idea due to Peter Landin which he calls a stream. The 
idea is that the elements of a list should be able to be dynamically 
computed instead of all of them having to be computed at once. Por 
example in debugging the elements of a list might be computed 
incrementally as they are needed by being input from a teletypewriter. 
ie could construct such a list |1| as follows: 

<monitor 

(0) 

;"the is a dummy which will 

be replaced with the first 
element read" 
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-»*read w > 

Here ve define f by: 

<de£ine £ . 

<f unction [1 u ?] 

<ionitor 

<rest 

~ (< replace <read» 

(replace (0)}) 
.1» 

;*nonitor the rest of the list *ith f« 
-* w read ,, >» 

How <1 |1|> is the first expression read, <2 1 i I > is the second* etc. 
<0HH0NITOB 

$11 )pat]> unaonitors the location | X 1 by all 
functions that natch J pat J. 

4.5.U2.4 Type 

<BBTBACT 

|xj> returns the value jxj retracted to the type in 
vhich it was defined. The function BETBACT is the identity function 
on objects of priaitive type. 

<ST0BAGB 

|x |> returns the primitive storage allocation type of 
J xL The priaitive storage types are LIST, ¥ECT01 # STBIBG, 
H0H06EB0US-VECTCB, STACK, BIBG, ATOH, ACTIYATIOM, JOBCTICI, LABEL, 
PROCESS, and BODE. 

<TIPE 
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|xj> returns the dynamic type of jxj. 
<DECLABED 

lxj> returns the declared attributes of jx|. The 
function DBCIABBD is useful in deciding how to expand nacros. 

<GETC 

|apparent-indicator| | object! *not-found*> gets the 
J apparent- indicator | component of |object| according tc the structure 
definition for <TYPE |object|>. 

<ATC 

|apparent-indicator| | object | +not-found*> returns a 
/^ locative to the | apparent- indicat or | ccaponent of |object| according 
to the structure definition for <TTPE J object ]>. 

<PUTC! -PERSISTENT 

I object | -properties-> puts -properties- on | object} 
according to the structure definition for <TTP1 |object|>. 

<P0TC!-TEHT1TIVE 

lobject] - proper ties-> is exactly like PMC except 
that the properties of (object | are restored on backtracking. 

4.5. 1.2.5 Synchronization 
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<iOCK 

-lock-specifications- > attempts to satisfy the -lock- 
specifications- where each lock-specification Bust be cne of the 
following: 

| location J aeans that | location | is to be locked if it is not 
already locked. 

r-«"BELOCK" jlocationj 3 aeans that Jlocationj is to be relocked 
ewen if it is already locked. 

£-."0 BLOCKED" J location J] aeans that Jlocationj aust be 
unlocked. 

The process which calls the function LOCK is suspended until all the - 

lock-specifications- are satisfied. Suppose that we have a data base 

that soaetiaes is aoaentarily in an inconsistent state while it is 

being aodified. We would like to set up locks so that arbitrarily 

aany processes can be reading the data base at one tine but only one 

process can aodify it at a tiae. suppose that each data base has a 

BE AD LOCK and a BBITELOCK coaponent in addtion to a COHtlHT coaponent. 

<define read-data-base <f unction rdb [data-base 3 
<prog [current-content ] 
<lock 

[-*" unlocked" 

<atc writelock .data-base>] 
[-•"re lock" 

<atc readlock . data-base> 3> 
;"in order to read the data base 
the writelock Bust 
be off and the readlock 
aust be relocked" 
<_ tcurrent-content <getc content .data-base» 
<unlock <atc readlock ,data-base» 
;"is done after the process stops reading" 
<.rdb ,current-content> 
;"exit .rdb with .current-con tent ">» 
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<define vrite-data-base 

<f unction [data-base new-content] 

<lock <atc vritelock .data-base» 
<lock <atc readlock ,data-base>> 
; n in order to write the data base the 



vritelock 



■ust be locked and 

then readlock Bust be locked" 
<putc .data-base [content .new-content ]> 
< unlock 

<atc vritelock . data-base> 

<atc readlock «data-base» 
;*is done after the process stops writing"» 



<LCCKEB 



♦checker* *activation-nane+ [-lock-specif ic at ions-] - 
body-> where the +activation-naae* and ♦checker* are optional attempts 
to achieve -lock-specif ations- execute the -body- and then unlock any 
locations that were locked by -lock-specifications-* The function 
^ LOCKER Bakes use of CAICH to insure that the locks are unlocked when 
+activation-naie+ is exited. Be can do the above exaaple as follows: 

<define read- data- base <f unction [data-base] 
<lccker [ ] 

[[ -i H un locked " 

<atc vritelock .data-base>] 
[^*relock w 

<atc readlock *data-base>]] 
<getc content *data-base»» 

<define vrite-data-base 

<f unction [data-base new-content] 
<locker [ ] 

[<atc vritelock .data-base>] 
<locker [J 

[<atc readlock .data-base>] 
<putc 

•data- base 

[content .new-content ]>»» 

<LCCKBD? 

^ -locations- > attempts to lock the locations which are 
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arguments. If the locations cannot be. locked, then the function 

LOCK ID? returns <>• 
<U BLOCK 

-locations-> unlocks the locations. 

4.5.1.3 Debugging 
<£BBQB 

(message |> will type out the message and go into an 
error loop. 

!%<block (<oblist error! -> <oblist>) > 

<de£ine error <f unction 

[^"cptxonal" [message -t"none"J] 

<print {-*"err or- message: * .message) ,console> 

; "print the message on the console channel" 

<repeat [-*"special" loop] 

[[ old-cut .out] 

;"save the old value of out in old-out" 

[-•"special" [culprit <frame 3>]] 

;"the culprit activation is the one three frames back* 

-*" labels" 

[^"special" [out <f unction [^"optional" [n 1]] 

;"the label procedure out handles 

exits from error loops" 

<cond 

[<is? <less t> .n> 

<again .loop>] 

I* - * "else" 

<. old-out <- .n 1»]»333 

<print <e?al <read»»» 

IX<ead-block> 



<DEBDG 

(status | > will set the state of tie debug state to 
{status | . The status lay be Von" or -*"off". 
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<BIND1HGS 

IP I> is the current set of bindings for the process 
IPl - 

<FHAHE> is the current activation fraae of the process which 
calls it. 

<FBAME | place | > is the last activation of | place] if | place | 
is a process and is | place | if |place| is an activation. 
<FB*HE 

j place | Jn|> is the activation fraae which is |n| 
fraaas back free | place). 
<PBOCED0BE 

]fraaej> is the procedure of J fraae}. 
/•> <HaHE 

I procedure )> is the oaae of I procedure | if it has one 
and <> otherwise. 
<PB0CI1HE 

I fraae | > is the naae of the procedure for | fraae |. it 
is equivalent to <M1HE <PB0CID08B 1 fraae |». 
<1BGS 

|fraae|> is the tuple of arguaents of |fraae|. 

4.5. 1.4 Identifier 

<ASSIG1ED? 

I varl lb!> is true onlj if the identifier |varl has 
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been assigned a value within the bindings |b|. 

<UNASSIGN 

JvarJ | )>i > nafces |varj unassigned within the bindings 

lb|. 

<BOUHD? 

|var| |b|> is true only if the identifier |var| is 
bound within the bindings JbJ. 

4. 5. 2 Examples of the Use of Functions 

The function factorial is defined below in order to illustrate 
the syntax of functions that produce values. On entrance to REPEAT, 
teap is iaaediately bound to 1. 



<define factorial , .,,.. *. rr ^ .11 

<f unction factorial [n] <repeat [[tenp 1]] 

<cond 

£<is? <less 1> .n> 

<. factorial .teap> 

;"exit .factorial with .teap"]> 

< :teap <* «n ,teap» 

<dec n»» 

Using a foe stateaent, we can define factorial as follows: 



<define factorial 

<f unction fact [n] 

<for 

[£teap 133 

[[-"dec" n -."thru" 1] 
[-."final" 

<.fact .te«p> 
;exit .fact with .teap"]] 
<_ :teap <* .n .teap>»» 
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Thus the value cf <factorial 3> is 6; and the value of <factorial <♦ 
2 2» is 2H 
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4.6 Actors in Patterns 



Examples of actors are VEL for disjunction , BOB for negation, 
ALL for conjunction, a 6a STAR for Kleene star in general regular 
expressions. He use the characters { and } to deli lit actor calls 
that are to Batch as segments. 

<prog [a b c] 

;"ve are inside a program, we have declared the 
identifiers a b and c. 

In the assignment statement below the pattern 
(k {all _a _b} _c) is matched against 
(k x y z)\ 

The pattern {all _a _b} matches an expression 
only if both a and ~b match the expression. H 

<is? (k {all _a _b) _c) {k x~y 2)» 

a gets the value (x y) 

b gets the value (x y) 

c gets the value z 

<prog fx c] 
r <is? (!_x {either (th) (t*)) *_c) (a o tm th)» 

x gets the value (a o) 

c gets the value (th) 

<prog [x] 

<is? ((star a} _x) (a a a a)» 

x gets the value a 

The argument of the actor 1HE1 is a list of clauses. If the object 
that the actor WHEN is trying to match has the property that it 
matches the first element of one of the clauses then it must match the 
rest of the elements in that clause. 

<prog £[l=*fix x]] 

<is? <*hen [<?> _x]> 3» 

x gets the value 3 since 3 is a fixed point number. 



$***s, 
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In the expression below <all _a _b> Batches 3 only if both _a 
and _b match 3* Thas both a and b are set to 3. 

<prog [a b] 

<is? <all _a _b> 3» 

A nuaber of actors are defined below* 

k palindroie is defined to be a list that reads the saie 
backwards and forwards. Thus (a (b) (b) a) , {)# and ((a b) (a b)) are 
palindromes. Hore formally in MATCHLESS, a palindroie can defined as 
an actor of no arguments; 

<define palindroie 
<actor [ ] 

;* palindroie is a actor of no arguients* 
<either 

<eipty> 

;*a palindroie is either eipty or" 

declaration [x] 

••♦declare a new local x m 
<list _x {palindroie} .x> 
;"let x be the first eleient of the 
linear structure. 
Also x lust 
b4 the last eleient 
with a palindroie 
in between 9l »» 

For exaiple 

<is? <palindroie> (a 1 1 a) > is true. 

The fori ACTOB is like the function of XISP except that it is used in 

actors instead of in functions. The above definition reads: a 

palindroie is a list or vector such that it is eipty or it is a list 

or vector which begins and ends with x with a palindfcoie in between. 

The actor SAAB causes the identifier x to be rebound every tiie that 

palindroie is called. The actor HBTBRSI is defined to be such that 



FORMAT OF ACTOR ACTIVATIONS 
IN SNAPSHOTS 



IDENTIFIER-BINDINGS 



RETURN-CONTROL 
▲ 



PATTERN 

BEING EVALUATED 



VALUE BEING 
MATCHED 



BACK 

TRACK 

CONTROL 



NEW ] 

, IDENTIFIER | 

| BINDINGS | 

NOTE : THE IDENTIFIER -BINDINGS 

AND RETURN-CONTROL POINTERS 
OF AN ACTIVATION ARE USUALLY 
THE SAME AND THUS ARE 
COMBINED INTO A DOUBLE 
POINTER LIKE THIS. 



A 

# 
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<is? <re verse .x> .y> is true only if the value of x is the reverse of 

the value of y. The definition of reverse is 

< define reverse 

<actor [x] 

<when 

[<Bonadic> 

;"if the object being Batched is aonadic 

then it Bust be equal to x" 
•x] 
[declaration [first rest] 

; "otherwise let first 

be the first element 
of the Batching object 
and rest 

be the segnent of the rest of 
the elements of the 
Batching object* " 
<linear _first !_rest> 
;"when <linear (reverse .rest} . first > 

Batches .x we are done" 
<be <is? 
^^ <linear 

*^ {reverse .rest) 

. first> 
.x>»]>» 

For exaaple 

<is? <reverse {x y 2) > (2 y x) > is true 

Hany of the ideas for the actors cose fros Post productions # 
BIF, general regular expressions, EL1IST (Slagle f s algebraic pattern 
Batcher), SHOBCL, COHVEBT, and LISP. Be give exa spies of the use of 
these actors afterward. 



4.6.1 Definitions of Ictors 



s-\ 
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4.6.1.1 Control Actors 



4 • 6 . 1 . 1 . 1 Conditional Actors 
<=« 

lx J > matches an object only if the value of |x| is 
identical to the object. 
<H0» 

| pattern ]> matches an object only if | pattern! does 
not aatch the object. Thus <non c> Hatches a, bat <non a> does not 
natch a. 

<?EL 

-patterns- > matches an object only if sciie pattern in 
turn matches the object. If a simple failure backs up to the actor 
VEL, then the next alternative pattern in turn is tried. If all the 
alternatives are exhausted, then TBI. itself propagates a simple 
failure backward. Per example 

<prog [[a 3]] 

<_ (<vel 4 _a> <♦ .a 1>) (4 5)» 
a is initialized to 3 
4 is matched mith 4 
<♦ 3 1> fails to match 5. 

_a is matched against 4 giving a the value 4 
<♦ 4 1> matches 5 

<prog [a^b] 

(<vel ?a ?b> ?a) 

(3 4)» 
a gets the value 3 

3 does not match 4 so a simple failure is generated 
a gets the value iunassigned 



/-N 



SNAPSHOT NO. 1 



/^"S 



<PR06 Co b3 
<IS? 



f*\ 




^KEITHER ?a ?b> ?a) 



(3 4)» 




SNAPSHOT NO. 2 




>(<EITHER ?a ?b> ?a) 



(3 4)» 




SNAPSHOT NO. 1 



/"> 



<PROG Cab] 
OS? 



^P«S\ 




* KVEL ?a ?b> Pa 



(3 4)» 




SNAPSHOT NO. 2 



<PR06 [ob] 
<IS ? 




*(<VEL ?a ?b> ?a) 



(3 4)» 




SNAPSHOT NO. 3 



a - 

b ~ 



/ ^ 




<PR06 [ob] 
< IS P 

*(<VEL ?a ?b> ?a) 



SNAPSHOT NO. 4 





TRUE 


a 


4 


b 


3 



* \ 




<PR06 [ab] 
< IS ? 

* KVEL Pa ?b> ?a) 
(3 4)» 




/-N 
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b gets the value 3 
a gets the value 4 

The following example shows how VB1 is different from BITHEB: 

<prog [a b] 
<is? 

( 

<either ?a ?b> 

?a) 
(3 4)» 

evaluates to <> which is false since EITHER does not try latching ?b 
with 3 because ?a successfully matched 3. 



<ALL 

-patterns^ > Batches an object only if each pattern in 
turn matches tie object* 
<IS-ACTOB 

| pattern | > will match an object only if the object 
matches the value of (pattern!* 
<BB 

(predicate) > matches an object only if the (predicate] 
is not false* In other words the actor BB ignores the object that it 
is supposed to match and considers only the value of predicate* 

<be <is? 3 3» matches anything 

<be <» does not match anything since <> is false, 
<HATCHING 

[JobjectJ Jtaill Jlocj] (predicate (> is exactly like 
the actor BE except that the identifier (object 1 is bound to the 
object being matched, I tail | is bound to its tail if it has one, and 
(loc( is bound to a locative to |object( if there is one* 
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<HHES 

♦checker* -clauses- > where each clause is of the fom 
[jpatternj -more-patterns-] or of the form •DiiCLABf [[-declarations-] 
Ipatternj -more-patterns-] matches an object if the first element of 
some clause in turn matches the object ana then the rest of the 
elements in that clause match the object. 

<prog [x y] 
<is? 

<when [<nuaber> x] [ y]> 

foo» 
;"y gets the value foo since foo is net a number" 



<prog [Mrfix [y 1] *]] 



<is? 

<when 



4» 

;«x gets the value 4* 



[<be <is? x <♦ .y 1>» 
<♦ .x 2>]> 



4.6.1.1.2 Block Structuring 

<DECLAfiATION 

[-declarations- ] -patterns- > matches an object only if 
each pattern in turn matches the object after -declarations- are 
bound. 

<_ #declaratiom[[x] _x ] 4> 
x gets the value 4 ~ 

<ACTIYB 

<| procedure | -args-> 1 place |> matches the pattern 
1 procedure | against all the currently active procedures nit h in 
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Iplacej. If the natch succeeds then -args- are latched against the 
procedures arguments. The J place | may either be a process or of the 
form [-»"BBT¥EES" | name 1 1 lname2|] where jnamelj and |naae2| are the 
names of blocks for a process. 



4.6.1.2 Data Actors 

4.6.1.2.1 Specialists 

4.6.1.2.1.1 Structure Actors 

Any expression delimited by * {" and ")" matches a list. Any 
f~s expression delimited by «[ n and n ]" matches a vector or a tuple. 
<?> matches anything. 
<? 

ln|> matches an object only if the object has length 
the value of \n\. For example the following are true: 

<is? <?> (b a c)> is true. 

<is? {{?)) ()> is true. 

<is? (a t?}) <a)> is true. 

<is? (a {?}) (a b)> is true. 

Something of the form • l«l matches only those objects which 
are equal to ixi. For example • .a matches .a and »a matches a. 

<? 

Jn| J pattern | > will match anything of length |n| which 

in turn matches 1 pattern J. 
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<prog [four- characters] 

<iS? 

£<? J> <? H :four-eleaents> <?>] 
[abcdefghi]> 
;"four-elenents has the value [d e f g]"> 

<STAB 

-pat terns- > Batches an object only if the object 
consists of a sequence (including the null seguence) of elements that 
■atch patterns. For ex a ■ pie <star 3> Matches {3 3 3) and (a (star b 
c} e) latches (a b c b c e) . 
<DAGGEB 

-pat terns- > Batches an object only if the object 
consists of at least one seguence of elements that natch patterns. 
For exaaple <dagger 3> Batches (3) and (3 3) but does not natch (). 
<OPTIOMS 

-patter ns-> Batches a seguence of eleaents which natch 
a subsequence of the patterns froa left to right* Por exaaple 
<options a !*fix !=atoa> Batches (a J). 
<BAS 

-properties-> Batches any object with the appropriate 
properties where each property is of one of the following foras: 

[I indicator | <fklh>} fails if there is an object under 
1 indicator J . 

present U*»aicatar|] reaoves the talue under the |indicator| if it is 

n«*«—*LiW 4c } tme l IHH) s?ys that the object has under the 
I indicator | a piece of data* which Batches th€ pattern J pal |. 



/*% 



/***% 
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The actor HAS allows HATCHLESS to do pattern Batching en arbitrary 
graph structures* The exaaple of the syntax of LISP given below shows 
how we can write grawwars over graphs* The idea of developing pattern 
structures over graphs has been generalised and extended in PX.AHHEB* 

< 

<has ["x" 3] £4] [c <replace 5>]> 
<node [c [4]] £4 5] [*x« 3 ]» 

evaluates to 

♦node £[*x" 3] [c 5]] 
<S£LECT 

J pat J (other |> latches any structue such that one of 
the elements of the structure watches jpat| and the reaainder of the 
structure watches 1 other |. 

<prog [r] 

<select 3 _r> <class 4 3 5> 

;*r gets the value <class 4 5>"> 

<0P 

Ipatj l collect! (other |> watches any structure stich 
that the list of all the elements of the structure that watch lpat| 
watches the pattern ]collect| ana the rest watch the pattern |other|. 
For exaaple 

<prog [integers others] 
<_ 
~ <of !*f ix integers _others> 
[a 3 b 5 9]» 
integers gets the value (3 5 9) 
others gets the value (a by 

<STB0CT0RI> 
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matches any list, vector, or node. 
<EHPTY> 

Batches any empty structure. 
<BCIAD> 

Batches any object which cannot be decomposed. 
<LINE&H 

-patterns- > Batches any list, vector, or tuple whose 
elements match the patterns in order. Per example <linear 3 4> 
matches (3 4) and it also matches £3 *l ]. 
<EUBHEST 

|x|> matches any object such that the object is an 
element of 1 x(« 

<COMTAIMS 

]pat|> matches any structure which contains an object 
that matches ipatj. 

!X<bloc* (<oblist containsl-> <oblist>)> 



< define contains 
<actor 



<container 

<eval !*<actor {) .y>»» 



<define container <actor [x] 
<«hen 



[<.x> 

;*if the actor x matches 

the matching object 
then we are done 99 ] 
[<monadic> 

; w if the matching object is 

monadic then fail" 
<fail>] 
[<linear <container • *> {?}> 
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;"if the first element in the 

Batching object contains x 
then we are done*] 

•"else the rest of the Batching object 

Bust contain x" 
<lioear <?> (container . x}>]»> 

!*<end-block> 
<BEP1AC1 

Jx|> Batches an; object. As a side effect the object 
which is Batched is replaced with the value of ]x|. 

<prog [y] 

<is? 

<all 

JI 
(<re place a> (replace (b)})> 

(c d e)» 

y gets the value (a b) 

We can define an actor rev which changes any list which it Batches to 
the reverse of that list. 

<def ine rev <actor [ ] 
<either 

<enpty> 
<linear <?» 
declaration [first last] 

<linear : first (?) :last> 
<linear 

<replace . last> 

(rev) 

<replace .first»»» 

Bow if evaluate 

< :c {e f c)> 
<Z <rev> .c> 

then c nysteriously has the value (g f e) because tke actor rev 
destroys the initial list to sake the reverse. 

<PRECEDES 
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|x|> will natch anj expression which precedes |xj in 
the total ordering on expressions* Pot example <precedes "c*> will 
natch "a w since "a" pr cedes "c*. 
<FOLLOBS 

Jx J > will match any expression which follows |x| in 
the total ordering on expressions* 

4.6. 1.2. U 1. 1 List 

<LIST!-DECOHPOSEB 

-patterns- > latches lists whose elements match - 
patterns-. It is equivalent to (-patterns-) . 

4.$. 1.2. 1.1.2 Vector 

<VECTQB!-DECCHPOSEB 

-pat terns- > matches vectors whose elements match - 
patterns-. It is equivalent to [-patterns-]. 

4.$. 1.2* 1.1. 3 String 

<SfRIIG!-DECOHPOSEB 

-patterns-) matches strings whose substrings match - 
patterns-. 

<prog [first rest] 
<_ 

<string !_first * * !_rest> 
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"see the boy">> 
first gets the value "see" 
rest gets the value "the boy" 

* * l <_ <string !_root "s"> "cats"» 
root gets~the value "cat" 

4.6. 1.2. 1. 1.4 Graph 

OODBl-BECOPCSIB 

-properties- > is equivalent to <kll !=»ODB <H1S - 

proper ties -»• 

4.6.1.2.1.2 Atci 

<ATO!l!-DBCOHBCSBB 
^^ |sj jo|> will Batch an atoi whose print naie is the 

string ]s| and vhich is on the oblist named )o]. 

4.6.1.2.1.3 Hord and Buiber Ictors 

<IBHBBE > latches an object only if the object is a nuiber. 
For exaiple <nuiber> latches 3. 
<1ESS 

|n|> latches any nuiber less than the value of |n|. 
<LESS- 

ln|> latches any nuiber less than or equal to the 
value of )n|. 

<G BE IT IB 
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Jn|> matches any number greater than the value of |n|. 
<G BE AT 1 8= 

|nj> matches any number greater than or equal to the 
value of |n|. 

<FIELDS 

•specifications- > matches any fixed point number which 
meet each specification of a field in turn* A fixed point number x 
meets a specification cf the form []bitsj | patternl] only if the 
number which is the byte of x defined by IbitsJ matches ) pattern!. 
The expression <bits \s\ 1 p I > defines a byte Js| bits wide which is 
Ip| bits from the right end of the word, 

<fields [<bits 3 0> 4} [<bits 1 35 > 1 ]> matches a 
fixed point number whose lower 3 bits are n and whose sign bit is on* 

4.6.1.2JJ Algebraic Actors 

The motivation for providing algebraic actors is to enable 
pattern directed algebraic simplification to be easily accomplished* 
Often it is not clear which simplified form is most useful. Using the 
hierarchical backtrack control structure of FJLAHHEB one fori can be 
tried as a hypothesis and then in tbe light of this experience perhaps 
another more suitable one, 

<!♦ 

-patterns- Irest-of-summandsl > matches a sum such that 
each pattern matches a summand and the rest of the summ^nds match the 



4.6 page 188 
pattern |rest-of-sunaands| . 

<is? 

<!♦ a b <?» 

'<♦ c b a» is true. 

<prog [y ? x] 
<xs? 

<!♦ <all <non c> jz> _y _x> 
»<♦ c b a»> 
z gets the value b 
y gets the value c 
x gets the value a 

<prog [y x] 
<is? 

<!♦ y b x> 

•<♦! c b d>» 
y gets the value 1 
x gets the value <♦ d c> 

<SUB-0? 
/**s IpatJ J terms-that- match- pat] lrest-of-sunaaads|> 

matches any sua such that the sum of the suaaands that match fpatj in 
turn aatch the pattern J terms-that-aatch-patl and the rest of the 
summands match the pattern Irest-of-suamands], 

<prog [y] 

<is? 

<sum-of <!* x <?» y <?» 
*<♦ <* 3 x> <* y a>>» 
y gets the value <♦ <* 3 x» 

<!* 

-patterns- |rest-of-f actors |> matches a product of 
factors such that each pattern matches a factor in the product and the 
rest of the factors aatch the pattern t re st-of -factors J . 

<is? <!* 5 b c> •<* c b 5» is true. 
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<prog [x y] 
<is? 

<!* <all <nunber> x> y <?» 
»<* <♦ 2 a> 3 a>»~ 

z gets the value 3 

j gets the value <+ 2 a> 

<prog [x] 

<is? <!* 3 jt 1> 0» 
x gets the value 

<PBODUCT-OF 

lpat| |factors-that-aatch-pat| J rest- of -f actors |> 
aatches any product of factors such that the product of the factors 
that aatch pat in tura natch ]f actors- that-aatch-pat| and the rest of 
the factors aatch the pattern Jrest-of -factors). 

<prog £x y] 
<is? 

<product-of <non <nuaber» x _y> 

!»<* a 3 b 5.0>» 
x gets the value <* a b> 
y gets the value <* 3 5.0> 

<POiEB 

|base| l exponent | > aatches an exponential. 

<prog [x y] 

<is? <po«er _x _y> »<expt y 2>» 
x gets the value y 
y gets the value 2 

<prog Tx j] 

<ls? < power _x _y> 0» 
x gets the value 

<EXTBACT 

J pat | | teras- vith-pat-extracted| | rest-of- teras |> 
aatches a sub of teras such that the sua of the teras which contain a 
factor which aatches |pat| aatches | teras- with-pa t -extracted J and the 
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f \ ■ .......... ... ., . ; 

sun of the rest of the terms latches the pattern |rest-of- terns | • The 
actor EXTBACT is due tc V« Bledsoe ♦ 

<is? 

<extract x <!♦ 3 a 0> y> 

|t<* |t<« a x> y 1 9 <* x 3>» is tree 

Joel (loses invented the exaaple of defining a guadratic in x 
using patterns • 

<define quadratic 
<actor 

[x a be] 
<ex tract 

<pover . x 2> 

<all <non 0> <non <contains «x» <*a>» 

<extract 

• x 

<all <non <contains • *» <«b>» 

<all <non <contains #x» <.c»» 

Thus if 

<prog [["special 19 a1 b1 d]J 

<is? 

< quadratic 

y 

<actor [J _a1> 
<actor [ ] b1> 
<actor [J c1» 
<!♦ 

a 

<!* 3 y> 

<!* z *<expt y 2> 4> 

<!* c y»» 



then 



a1 gets the value <* z <t> 
b1 gets the value <♦ 3 c> 
c1 gets the value a 



«.$. 1-2.U5 locative 
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4.5.1.2.2 Type 

<OF-T?PB 

JatoaJ> Batches an object Jo J only if <«»? <TYPB Jo|> 
}atoa]> i.e. only if |c| is of the type Jatoa). The expression <0F- 
TIPE Jatoa]> aay be abbreviated as !=Jatoa|, 
<AS 

IpatJ Jinjj> matches an object x only if x is of the 
type of the range of the injection |inj| and <RETBACT x> aatches the 
pattern IpatJ. 

4.6.1.3 Identifier 

<GIVEH 

lthetaj -bindings-> acts like <¥AL0E Jthetaj - 
bindings-> if the identifier lthetaj has a value. Otherwise <GI?BB 
lthetaj -bindings- > Batches an object x only if the identifier lthetaj 
aatches x. 

?|theta| is an abbreviation for <GIVEH |theta|> 

l?Jtheta| is an abbreviation for {GIVE! Jthetaj} 
<ALTBB!-PBBSISTBBT 

jthetaj -bindings- > aatches any expression x which 
aatches the identifier Jthetaj and gives lthetaj the value x. 

: Jthetaj is an abbreviation for <A1TBB Jtheta|> 
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!:|theta] is an abbreviation for {ALTER Jtheta)} 
<ALTER!-TE8TATI¥E 

Ithetal -bindings- > Batches any expression x which can 
natch the identifier Jtheta |. The identifier Jthetaj is given the 
value x. However, if a failure backtracks to ALTEB1-TEHTATIVB, then 
ithetal is restored to its previous value* 

_|thetaj is an abbreviation for <ALTEBI-TEHTATI?E 
ltheta|> 

!_|theta| is an abbreviation for {ALTEB!-TEHTATI¥E 
Ithetal} 

4.6.2 Examples of the Use of Actors 

The rest of our examples of the use of actors come from giving 
a rigorous definition of the syntax of LISP in MATCHLESS* Those 
readers who are not interested in the details of the syntax of LISP 
should not read section 4.6.2 The following grammmar accounts for 
essentially all the context dependent features of the LISP syntax. It 
specifies that a function call must have the right number of 
arguments. An explicit go must have a tag to which it can go. The 
syntax specifies that some identifiers are free and others are bound. 

<define top- function <actor [ ] 
declaration 

[["special* [tags ()] [boundvaxs () ]]] 
(function <varlist> <form>)>» 
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Thus for example <top-f unction> matches (function () ())• The actor 
top-function introduces the pattern identifiers tags and boundvars and 
binds them to - - which is the null segment* 

< define varlist <actor [ 3 
<star 

declaration 

[ [ ! =a t om cur var J ] 

_curvar 

<be <is? _bouodvars {-cur var ! ♦boundvars) >»>» 

The actor varlist checks each identifier in turn to make sure that it 
is an atom and then puts the identifier in boundavars. 

<define 

form <actor [ ] 
<vhen 

[<monadic> 

<either <constant> <*ar»] 

C 

(!-atom {?}) 
<vhen 

[(prog [?}) 

<progform>] 
[(cond [?}) 

<condform>] 
[<setg {?}) 

{<?> <*ar> <f orm>) ] 

[(go {?}) 

<gof orm> ] 
[ «has [subr <?>]> £?J) 

(<?> {star <form>}) ] 
[ (<has [expr <?>]> {?}) 

<exprform>] 
[ (<h*s [fexpr <?>]> (?}) 

[ (<has [fsubr <?>]> {!}) 

[ (<has [Xsubr <?>]> {?J) 

{<?> (star ^f orm>) ) ] 
[{<has [lexpr <?>]> £?}) 

(<?> {star <form>})] 
[<?> 

<matcning 
- [expr ^"optional"] 
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<print (.expr undefined) »]>] 
[{(function {?)) {?)) 

<f unction w f uncticn> ] 

(<fora> (star <f orn>}) ]>» 
The above definition says that if a fora is a aonad then it aust be a 
constant or an identifier; if its first eleaent is an a tea then if it 
begins with the atoa prog, then it aust be a progfora etc.; if it 
begins with "( (function .«) •• ) ■» then it aust be a function-function; 
otherwise it aust be a fora followed by a foralist. 

<define constant <actor [ ] <either t () <nuaber»» 
The only constants are t, {) , and nuabers. 



<define ?a? <actor !=atoa [] 
< either L J 

<eleaent •boundvars> 

<unbound»» 

An identifier is either in bound vars or it is unbound. 



<define condfora <actcr [] (cond {dagger ({star <fora>})})» 

progfora <actor [ ] 
<declaration 

C 

[ "special " 

[tags .tags] 
[local tags () ] 
[bonndvars .bound wars]]] 
(prog 

<varlist> 
{all 

<collect-tags> 

<be <is? _tags (!. local tags !.tags)» 

<star <either !=atoa <fora>»})>» 
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On entrance to progform tags and boundvars are rebound to their 
previous values. The prog identifiers of the prog are put in 
boundvars, the tags in the prog are put in tags by collect-tags, and 
the body of the prog is checked to see if it is well foraed, 

<define 

collect-tags <actor [ ] 
<star 

<either 

<declaration [ 

[ !-atoa curtag] 
["special 1 * localtags]] 
curtag 
<be <is? 

^localtags 

{<• curtag ! . localtags) » 
<when £<eleaent . local tags> 

<error "aultiple defined tag">] 

<define 

exprfora <actor [ ] 
<declaration 

[args functicnvar] 

( 

<has [expr (function _functionvar {?})]> 
{all <star <fora» _args|) 
<be <=-? <length • function var> <length •args»»» 

An exprfora is a call to an expr with the correct nuaber of arguments. 
Bote that iaaediately inside the actor exprfora the identifierss args 
and functicnvar are rebound but reaain unassigned. 



<define gof ora <actcr [ J 
(go 

<when 

[ !*atoa 

<either 

<eleaent .tags> 

<print (.curtag undefined tag)»] 

[<fora>]>)» 
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A gofora is either an explicit call to go to a tag which Must be in 
.tags or a computed go. 



<define . , 

f unctxon-f unction <actor [ j 

declaration 

[args functionvar } 

( 

<declaraticn 

[••special" [boundvars (.boundvars) ]]] 
(function 

<all <varlist> Jt unctionvar> 
<fori>)> 
(all <star <fora» _args}) 
<be <«? <length .functicnvar •args»»» 

la a function-function the bound identifiers of the function anst be 
added to boundvars and the function-function aust have the proper 
/"^ nuaber of argaaents. 

The above syntax could easily be extended in several 
directions* For example ve could easily aodify it so that it would 
accept type declarations and do type checking* The syntax of 
ttATCHLESS could easily be defined in HATCHLESS. 
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4.7 HOBBLE 



Section 4.7 is logically completely separate from the rest of 
this report. It is not necessary to read this section to understand 
the rest of the document. 

le are interested in exploring good nays to implement systems 
like PLAHHEH on machines, one way is to embed the systei in a 
language like LISP or PL-1. The problem »ith embedding is that the 
host language has its own conventions foj: calling sequences and saving 
temporaries. The conventions might not be compatible with the system 
shich is being implemented. Another approach is to try to develop a 
formalism which is sufficiently flexible so that it can adapt to the 
higher level system conventions but still is efficient enough so that 
it is feasible to use as an implementation language. The applicative 
sublanguage of HATCHLBSS seems to be at approximately the right level 
with the restriction that the data are no longer have types associated 
mith them at run time. Thus all the type information must be able to 
be processed at compile time. The general type definition formalism 
remains although the definitions must be processed at compile time. 
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4.8 The Editor 

<EDIT 

lx|> enables editing the structure |x| • The editor 
maintains a special identifier CUBS0B1-EDIT which represents the 
position of the editor within the structure. & command may be 
abbreviated by the first letter in its name. The editor lakes use of 
the tentative versions of the structure modifying commands so that the 
results of a series of edits can be undone by backtracking. Gregory 
Phister made suggestions and implemented an editor* 

<BEHEATH | cursor 1> is the expression beneath }cursor| or <> if 
there is none. 

<COHTAIHS | cursor J > is the structure which contains (cursor I 
or is <> if there is none. 

<ABC l cursor 1> is the indicator under which <BEHBATa 1 cursor) ^ 
is found under <COHTAIHS Icursor|> or is <> if <CC1TAXHS I cursor |> is 
<>. That is if <C0BTAZ1S | cursor I > is not <> then: 

<get 

<contains tcursor|> 

<arc | cursor J >> is <beneath | cursor I > 

<60 In 1 | cursor J > moves (cursor I £nj positions to the right if 
|n| is positive and ]n| positions to the left if | n| is negative. 

<IA1K |n| |cursorJ> walks (cursor | |n| positions around the 
tree. 

<0P In| |cursorj> rises through In] levels of structure from 
I cursor! . 

<DOWH }n I j cursor | > descends through |n] levels of structure 
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froa J cursor J. If Jn) is positive the cursor is acred down to the 
right otherwise to the left. 

<SIARCB .{pattern] Jn| | cursor |> searches for the Jnjth 
occurence of an object that Batches J pattern J • If jnj is positive the 
search is to the right, otherwise to the left. 

<FIBD {pattern} In] {cursor |> will conduct the search only in 
the object under ] cursor). 

<RBPLACE J pattern | Jx| ]nj | cursor |> replaces JnJ occurences 
of objects that aatch 1 pattern! with the value of |x|. If In] is 
positive the search is to the right, otherwise to the left. 

<CHAH€B | pattern] JrJ In J Jcursorp changes |n| occurences of 
objects that natch | pattern] with the value of |z| on the structure 
which is under J cursor J. 

<ISSEBT -expressions- |cursor|> inserts -expressions- into the 
structure. 

<KILI |n] J cursor I > deletes the expression under the cursor 
and <- in] 1> expressions following it. 



/**\ 
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5. PLAHHEB 



The PLAHHEB formalism incorporates a unified set of problem 
solving primitives that run under a multiprocess backtrack control 
structure. The formalism itself is independent of any particular 
problem solving domain. The primitives of the formalism uake default 
decisions in the course of a computation in those cases where the 
information supplied dees not specify exactly what is to be done. 
However, as a matter of principle each primitive allows a continuum of 
expression from no preference at all doirn to the specification of 
exactly one choice. The formalism is intended to be used as a matrix 
/^ in which the necessary domain dependent knowledge can be embedded, 
Hany of the primitives rely or side effects to accomplish their 
purpose, Although the use of side effects is in opposition to some 
theories of good language design, their use in PLAHHEB has worked out 
well. The formalism encourages modular programming through the use 
of specialized routines to satisfy goals and make deductions. 

The name PLAHHEB comes from the desire to create a formalism 
in which it is easy to express plans of action. To construct a plan 
in the formalism is the same as constructing a PLAHHEB theorem, 
flixing planning and deduction is guite easy. Conditional plans are 
explicitly provided for as is the ability to backtrack in case of 
failure. 

Consider a statement that matches the pattern [IEPLISS |t| 
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lyl]. The statement has several imperative uses* 

st1: If we can deduce ] x| , then He can deduce Jyj. 

In PLANNER the statement st1 would be expressed as ANTECEDENT £] |xj 
<ASSERT Jyi» which means that |x| is declared to he the antecedent of 
a theorem such that if ]x| is ever asserted in such a way as to allow 
the theorem to become activated then |y| is asserted. 

st2: if we want to deduce )y|, 

then establish a subgoal to first deduce |xi. 

In PLANNER the statement st2 would be expressed as 

CONSEQUENT £ 3 lyl 
<G0AL ix|> 
<ASSEHT !yj» 

which means that |y| is declared to be the consequent of a theorem 
such that if the subgoal JxJ can be established using any theorem then 
the consequent ]y| is asserted. 

We could also assert <CLA0SE £ ] [HOT |xl] jyj> which is a 
clause which says that [mot JxJ] or |y| is the case. PS.A8HER has goal 
oriented primitives for using and manipulating all of the above 
variants. For certain purposes any one of the variants can be more 
useful than the others. Imperative information and heuristics can 
more easily be expressed in the procedural variants. For example 
heuristic information as to when we should create a subgoal x in order 
to achieve y can more easily be incorporated into a CONSEQUENT 
theorem* [On the other hand we can more easily deduce <CLA0SE £] c 
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d> fro* <CLA0SE [] x £H0T y] c d>] Of coarse the distinction is not 

sharp since the two kinds of assertions can be coabined by making 
assertions about the actions of iapecatives. 
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5* 1 PLAHHBfi Forms 



5.1*1 Hierarchical Backtrack control Structure 

PLAHHEB uses a control structure in which the hierarchy of 
calls is preserved so that a coaputaticn can backtrack to an 
activation from which it has already returned. Backtracking preserves 
the nesting of block structure. It simply traverses the statements 
executed in reverse order. The primitive functions FAIL and FAILPOIHT 
enable the backtrack process to be controlled. The form <FAIL> 
generates a siaple failure which backtracks to the most recently 
executed form 

<FAILPOIHT *activation-naae* [-declatations-] 
{expression | 

[I message! {activation | ] 
-body~> 

Where J message] is bound to the message of the failure and the 
predicates are evaluated to try to find one which is true. For 
example 



<prog t[x^3] ] 



<prog f oo I j 

<f ailpoint [ ] 
• x 

O* optional" ] 
<*foo <_ u 4» 
;*exit Tfoo with H»» 
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;*the first tiae through the above expression 

has .1 as its value" 
<cond 

[<is? 3 .x> 
<fail>] 
[-•••else 11 
5]>» 

evaluates to <+ 4 5> which is 9. 

The identifier x is declared to be a fixed point integer which is 
initialized to 3. The value of <failpoint [ ] .x [ -»" optional 11 ] <_ :x 
4» is 3. Bhen the second argument of the call to •♦« is evaluted the 
conditional detects that x is bound to 3 and so generates a staple 
failure* The failure backtracks to the call to PAILPOIUT with the 
nessage <> which is fkLSE. The identifier x is assigned the value 4 
and the rest of the computation proceeds noraally. 
/"> The top level function of PLAHM1 is a read, evaluate, print 
loop* ahen tke expression read is successfully evaluated then the 
ahole hierarchy of calls is forgotten, the value is printed, and the 
process repeats • 

One of the aost straight forward ways to iapleaent 
hierarchical backtrack control structure is through the use of a 
backtrack stack on which backtrack information is stored. The only 
tricky point coaes in the ex£cnton of an exit where the temporaries 
aust be pushed onto th^ backtrack stack before doing the exit. The 
other straight forward method of iaple mentation is not to have a stack 
at all but rather to keep all the activation fraaes in garbage 
collected storage. The stack iapleaentation has the advantages that 
it keeps a smaller working set and doesn 9 t cause garbage collection. 
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The swamp implementation has the advantages that it is conceptually 
cleaner and is more flexible* The ideal implementation is to be able 
to run either mode. In stack mode the acivation records are simply 
tuples on the stack. 

The use of backtrack control structure has the important 
fringe benefit that it allows us to debug more easily* we have 
available the following control prmitives. 

<STEP Jp| in I ]condition|> executes the process {pi for in] 
elementary steps unless the J condition | is met in which case it 
returns the number of elementary steps completed* If ] n J is negative 
then the process is executed BACKWARDS! This enables us to zero in on 
bugs by running forwards and backwards until the bug is found* 

<IHVCKB )pl |n J )condition]> executes the process ipi for ln| 
procedure invocations unless the (condition I is met in which case it 
stops and returns the number of procedural invocations which have been 
completed* Again if (nf is negative then the process is run 
backwards* 

5. 1.2 PLANNEB Functional Forms 

The functional forms in PLANNEB are FOHCTICH and ACTOB* The 
sole change in the semantics is that the functional forms of PLANNER 
can handle pattern directed invocations* 

The following example illustrates the syntax of functional 
forms* The function AflOHG which is defined below is a generally 
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useful PLAMNEB function, ihat AMOHG does is to successively return 
the eleaents of the structure given as its argument. For example 
<among £E A]> returns E as its value. But if a simple failure 
backtracks to it then it returns A as its value and continues the 
computation. But if still another simple failure backtracks then it 
allows the failure to continue to propagate through the function 
AHONG. The particular way in which the function AHONG is used here 
does not accomplish anything that cannot be done easily in LISP. Re 
give this example because it is simple enough to be easily understood. 
One way to assign to the identifier x the value which is the first 
element of .list that is greater than 5 would be 



<is 



{{?} <all <greater 5> :x> {?}) 
.list> 



Another way would be <is _x <larger 5 <among .list>» where 



<define |f °|f p <f ™cti« a »unaer £ list ] <prog [first] 
<> 

; "establish a fail point and return <>" 

[m a? ] 



if 



;"on backtracking let m be the message and a? be true 

the failure will propagate through" 
<cond 

£<not? <is? .n <>» 

;"if the message is not <> 

then restart the failure" 1 
[<is? .m <» J 

;"the message is <>" 

<restoxe .for war d> 

;" start going forward agai 

with the failpoint restored" 1» 
<cond * 

[<empty? .list> 
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;*if list is empty generate a 

simple failure out of among* 
<fail <> * lunger :>] 
[-."else" 

< <linear : first !:Iist> .list> 
;«set first to the first of .list and 

list to the rest of .list" 
<. hunger *first> 
;«ex it -„aung.er vith . first" ]»» 

<define larger <f unction [a b] 
<coad 

[<is? <greater *b> .a> 

;«if a is greater than b then return a" 

• a] 
r -* " © l se " 

•"otherwise generate a failure with the Message <>" 

<fail 0>]>» 
Thus the value of <larger <anong (2 *» 6)> 5> is 6. 



5.1.3 PL4HSEH Theoreas 

PLASHES allows procedures to lie invoked by a pattern which 
states what the procedure is supposed to accomplish. 

There are four kinds of theorems which are presently defined 
in the language for satisfying requests made in the body of 
procedures: 

1. Consequent theoreas for satisfying goals. Consequent 
theoreas are the nost fundanental in the sense that they can easily be 
used to simulate the other two Kinds of the3reas. 

2. Antecedent theorems for deducing the conclusions of 
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assertions 

3* Erasing theorems for deducing conclusions from the fact 
that some assertion is no longer true 

t*. simplifying theorems are for simplifying expressions. 



5.1*3.1 Consequent 

<CCHSIC0ENT 

-type* ♦activation-name* 

| declaration -specif ication I 

J consequent- pa tternl 

-body-> 

evaluates to a procedure which declares that | consequent-pattern I is 

the consequent of a theorem which can be used to try to establish 
goals that match the pattern 1 consequent- pat tern I • ihether or not the 
theorem actually succeeds in establishing the goal depends on the 
body* Typically the first action that a theorem of type consequent 
takes is to try to reject the goal* Be cannot emphasize too strongly 
the importance of analyzing the consequences of goals in order to 
reject the ones which cannot be achieved* Even if no absurdity is 
detected , the consequences are often just the statements that are 
needed to establish the goal. The only way that a theorem that begins 
with the atom consequent can be called is by the pattern directed 
call: 

<CA1L 

[<[GOAi. I goal-pattern I ]> 
(recommendation | 
| state-path I ]> 
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which attempts to satisfy the goal I goal-pattern J where 1 consequent- 
patternj Batches | goal- pat tern | and the consequent theorea is in the 
data base specified by | state-path j. ?he function CONSEQUENT is 
defined to bez 

<f0NCTI0H ♦checker* +activation-naae+ 
£-."PlTTEBM" 

£ (declarations! [GOil (consequent-pattern I m 
-body-> J 

The following theorea says that if it is our goal to prove x and we 
have proved that ¥ iiplies x then ve should sake it our goal to prove 
v. 

<conseguent £x w] ?x 

<curreot {iiplies ?v ?xj> 
f~\, <goal ,w>> 

The following theorea says that two things are equal if they are 
identical. 



<c on sequent £x] £ = ?x ?x]> 

Mith this consequent theorem, evaluating the following causes: 

<prog £a] 

• "declare an identifier a" 

<goal I' ?a 3]> 

;"a gets the value 3 since a is linked to the 

identifier x in the consequent theorea"> 

<prog £a cj 

; "declare a and c" 
<prog Ob] 

; "declare b" 
^ <goal [« ?a ?b]> 
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;"a is linked to b" 

<goal [~ ?b ?c]> 

;"b is linked to c"> 
<goal [= ?A 3]> 
;«a gets the value 3 and so 

therefore c gets the value 3"> 



5.1.3.2 Antecedent 



<aHT2CEDEHT 

♦checker* 

1 declaration-spe cif ication 1 
| antecedent* pattern) 
-body-> 
evaluates to a theorei which declares that I antecedent-pattern! is the 

antecedent of a theorei froi which conclusions nay be drawn by the 
body. The theorea can be used to try to deduce consequences froi the 
fact that a statement that latches the antecedent has been asserted. 
The only way that a theorei that begins with the atoi antecedent can 
be called is by the pattern directed call: 

<CALL 

[<£ASSEHT | assert-pat tern J ]> 
I recoiiendation | 
| state-path 1 ]> 

which draws conclusions frci Jassert-patternJ where Jassert-patternl 
natches Janteceden t- pat tern | the aatecedndent theorei statisfies 
1 recoiiendation) and the antecedent theorei is in the data base 
specified by Jstate- pathj . The function AHTECEDEB? is defined to be: 

<EUHCTI0H ^checker* ♦activatioa-name* 
[-.•P1TTERB" 

[ | declarations J [1SSBBT | antecedent- 
pattern J 33] 

-body-> 
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The following theorea says that if we assert soaething of the fora 
[not [implies X YJ] then ve should deduce X. 

Antecedent [x y] [not [iaplies _x _yj] <assert .x» 
The following theorea says that if soae thing of the fora [aarry |x| 
Jyl] is asserted then [bachelor JxJ] should be erased. 

Antecedent £x y ] 

[aarry _x _y] 

<erase [bachelor .x]» 

5.1.3*3 Erasing 



<EBASIHG 

-type- 

J declaration-specification ) 
| erasing- pat tern j 
-body-> 
can be used to try to deduce consequences froi the fact that a 

stateaent that aatches the pattern ] erasing- patter n| has been erased. 
The only nay that a function of kind erasing can be called is by the 
expression 

<CALL 

[ <[ EBASE | erase-pattern | ]> 
1 recoaaendationl 
I state-path | ]> 

which expresses the fact that there has been a change in the world 
affecting | erase-pattern} ahere ] erase-pattern | aatches lerasiog- 
pattern|. The functicn EB1SX1G is defined to be: 

<P0HCTIOM ♦checker* +activation-naae* 
[-"P4T5EBI" 

[1 declarations | (EBASE I erasing- pattern | ]]] 
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-body-> 
The following theorem says that if something of the form [alive x] is 
erased tfees [dead x] should be asserted. 

<erasing [x] 

[alive _x] 

< assert [dead .x]» 
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5.2 PLAHNEB Punctions 



5.2.1 Data Priaitives 

Soae of the functions in PLANBEB are given below together witk 
brief explanations of their purpose Examples of their use are be given 
iaaediately after the definition of the priaitives below. The 
priaitives probably cannot be understood without trying to understand 
the examples since the language is highly recursive. In general 
PLANSEE remembers everything that it is doing on all levels unless 
comaanded to forget soae part of this inforaation. The default 
response of the language when a siaple failure occurs is to backtrack 
to the last decision that it aade and to aake another choice. 

<C AH DI DATES 

Ikindj (pattern] | state-path|> are the |kind| 
candidates that have the saae coordinates as | pattern | and are in the 
local data base defined by Istate-patbJ . CANDIDATES is the basic 
retrieval function foe the data base. The candidates can be generated 
incrementally if it is not desired to construct thea all at once at 
the beginning. The kind of data retrieved nay be: 

CUBE EST for assertions 
PUBCTICH for functions 



5.2 page 214 
5. 2.1*1 Assertions 

<ASSERT!-TENIATIVE 

(statement] Jrec] [-•"PATH 1 state-path 1 ] [^"ALREADY" 
| already-current 1 ]> puts jstatementj in the aata base defined by 
jstate-pathl ar3 tries to draw conclusions according to the 
recommendation Jrecj. Recommendations are optional; the default 
recommendation is [-^TBX*] which says not to try any theorems. If the 
statement is already in the data base then | already-current J is 
evaluated. If the value of 1 already-current I is ^"REASSERT" then the 
jstatementj is asserted in the first element of Jstate-path| . The 
-•"reassert* feature is due to Drew HcDermott. Otherwise, the function 
ASSERT causes the statement statement with properties to be inserted 
in the data base which is the first element of Jstate-pathJ . Then 

<CALL 

[<[ ASSERT |statement| ]> 
J state-path 1 
Jreci ]> 

is evaluated to draw conclusions from statement. If the call to DRAH 
ultimately fails then jstatementj is removed from the data base. The 
argument | already-current! is due to Peter Bishop. The recommendation 
is optional. The value of the function ASSERT is the arc from the 
state which contains the assertion having as indicator the assertion. 

<assert 

<put 

[subset a b] 
[difficulty trivial ]» 
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asserts that the set a is a subset of the set b and pat the value 
trivial under the indicator difficulty. 

<ASSEBT!-PEBSISTEHT 

(statement] Jrecl [-"PATH | state-path | ] [-*"ALBEAET" 
| already-current | ]> is exactly like ASSEBTI-TEHTATIVE except that 
1 statement ( is not withdrawn froa |state-path] on backtracking. 

Expressions of the form <CLADSE [declarations] -alternatives-> 
denotes an assertion with variables declared followed by logical 
alternatives. For exaaple 

< assert 

<clause [[<set> x y z]] 

[not [subset ?x ?y]] 
[not [subset ?y "?z]j 
[subset ?x ?x]» 

asserts in declarative fora that the subset relation is transitive for 
sets. In other words it is equivalent to 

<assert 

<clause [[<set> x y z]] 
[ iaplies 
[and 

[subset ?x ?y] 
[subset ?y ?z]] 
[subset ?x ?2jj» 

Another kind of assertion is one which has variables which are 
consumed by being bound For exaaple if we translate the assertion 
that John is somewhere as <assert <closure < clause [ ] [ at John ?x]> 
x» # then <goai [at John store ]> causes x to be bound to the atoa 
store. Thereafter <goal [at John hoae]> fails since the identifier x 
was consuaaed in being bound to the atoa store. The above problem was 
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suggested by Gene Charniak. 

W. Bledsoe suggested trying the problem of shoving that [all a 
[some b (p b a]]) follows froa [soae x [all j [p i !]]]• 

<assert <clause [y] [p [xO] ?y ]» 
<prog [b] 

<goal <clause [p ?b [a0]]>» 

b gets the value [xO] 

The expression <clause [y] [p [xO] ?y]> is the assertion Skolea fora 
of the assertion [soae x [all y [p x y]]] where xO is the Skolea 
function for x* The expressions <clause £p ?b [a0]]> is the goal 
Skolea form of [all a [some b [p b a]]] where aO is the Skolea 
function for a* On the other hand if we were to try to derive [soae x 
[all y [p x y]]] froa [all a [soae b £p b a]]] we would fail: 

<assert <clause [a] [p [bO ?a ] ?a]» 
<prog [x] 

<goal <clause [p ?x [yO ?x]]>» 

The identifier x cannot be be bound* The many-sorted omega order 
quantificational calculus of PLAHNBB allows for the possibility of 
null domains. For ex a i pie it does not follow that there is a god 
which is a deity if we assume that all gods are deities* That is 
[soae [in g god] [deity g]] does not follow from [all [in g god] 
[deity g]]« Thus we cannot prove the existence of a god so easily. 
However [soae [in g god] [deity g]] does follow froa [seme [in g god] 
[aythical g]] and [all [in g god] [implies [mythical g] [deity g]]]# 

<assert [mythical [g0]]> 
<assert 

<clause [[<god> g]] 

[not [mythical ?g]] 
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£ deity ?g]» 
<prog [[<god> x]j 

<temprog [ ] 

<assert <clause [] [not [deity ?x]J» 
; "assert that there are no gods which 

hate the property of being deities'* 
<prog [ literal 1 lit era 12] 
<current 

<clause 
<all 



<current 

<clause 
<all 



[deity <?>] 
_literal2> 



[not [deity <?>]] 
.literal 1> 



<box>» 

<assert 

<resolve 

•literal 1 
.literal2>» 
; "resolve a clause which contains an element 
^ which Batches [deity <?>] and 

a singleton clause 
whose eleient Batches 
[not [deity <?>]] producing 
<clause [] [not [aythical ?x]]> which 
is then asserted** 
<prog [ literal 1 literal2] 
<current 

<clause 
<all 



<box>» 

<current 

<clause 
<all 



[aythical <?>] 
_literall> 



[not [aythical <?>]] 
_literal2> 



<box>» 

<assert 
< resolve 

. literal 1 
.literal2>» 
;** resolve two singleton clauses; 
one containing 
a positive instance of aythical and 
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one a negative Instance* 

this binds x to [gO] and produce a 

clause which is written <box>* 
<current <box» 

;"thus we have derived the null clause which 
is a contradictions 
<assert <clause [] [deity *x]>» 
;«asseift £ deity [g0]]« 



5.2* 1.2 Erasures 

<EBASE!-IENTA1I.VB 

(statement | JrecJ [-•"PATH* |state-pathi ] [-"HOt-FOUHD* 
{not-found} ]> tries to find an assertion |a| in Jstate-pathl in the 
data base that matches {statement} • If such an assertion Ja| is found 
then it is erased and 

<Cilt 

£<[EBASB |ai ]> 

{recommendation] 
|state-pathj]> 

is evaluated to assay the implications of the change* If no such 
assertion is found then Jact-fonjidl is evaluated. If the change 
statement fails or if a failure backtracks to the function EB AS!, then 
|a{ is reinserted in the data base and the whole process repeats with 
another statement from the data base* the value of the function BBASE 
is am arc from an element of | state- path | with indicator a statement 
which matches 1 pattern |« The reader should be careful not to confuse 
what happens mkem the function ERASE is called to remove something 
from the data base with what happens when an ASSBBTIOH fails and thus 
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removes what was asserted froa the data base. The function BBASE Bay 
atteapt to do pattern directed invocation to deduce consequences of 
the deletion whereas ASSEBT will not. the arguaent J not-found | is due 
to Peter Bishop. 

<erase [on-top-of brick 1 brick2]> erases the fact that brick 1 is on 
top of brick2. 

<EBASB l-PBBSISTEHT 

Istateaent] trec| [-."PATH" ] state- path | ] [ -."HOT-FOOHD" 
|not-found|]> is exactly like the function EBASEI-TEBTATITB except 
that the assertion deleted froa | state-path J is not re-inserted on 
backtracking. 

/"""N 5.2.1.3 Goals 

<COBBEHT? 

1 pattern J | state-path |> tests to see if a statement 
that aatehes | pattern) currently is in (state-path!. If there is such 
a stateaent, then the identifiers in 1 pattern | are bound to the 
appropriate values. If there is no such stateaent, then CUBBEHT? 
returns false, if a siaple failure backtracks to the function 
COBBBST, then the identifiers that were bound are unbound. Then the 
whole process repeats with another stateaent in the data base. 

PLAHBEB is designed so that the tine that it takes to 
deteraine whether a stateaent that aatches pattern is in the data base 
or not is essentially independent of the number of irrelevant 
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statements that have already been asserted. A coordinate of a 
structure is defined by some atom, number, or string being in some 
position of the structure. When an s-expression is asserted PLaBHEB 
remembers every coordinate that occurs in the s-expression. Two 
expressions are siailar on retrieval only to the extent that they have 
the sane coordinates. The function <bEBGB |v| |1|> will nerge |r| 
into the list |1|. Consider the simple assertion 

< assert „z [-."path" (.s1) ]> where st is bound to a state and z 
is bound to -£a £b c]] causes the following changes: 



P ° <position 1 current> 

£* 

<nerge 

<get a 

< position 1 current> 

(0) 

;"if the bucket is empty then, 
initialize it with 
an empty list«»]> 

<P < posit ion 1 <position 2 current» 

<aerge 

• z 
<get b 

<position 
1 
< position 2 current» 

(0)»]> 



<put 



<position 2 <position 2cuttat» 

[c 

< nerge 

.z 
<get c 

<position 
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2 

<position 2 current» 
(0)»]> 

<put .s1 r.z -•"asserted"'^ 
Classes are stored in tuckets under the position ^"class". Thus the 

assertion <assert .w |>»path« (.s1) ]> where w is bouna to [nonempty 
<class e £>] would result in: 

<put 

<position 1 current> 
[ncneapty 
<nerge 

<get nonempty 

<position 1 current> 
(0) 

{••if the bucket is eapty then, 
initialize it with 
an eapty list"»]> 

/-v <put 

<position -•"class 11 <position 2 current» 

<aerge 

• v 
<get e 

<position 
^"class" 

<position 2 current» 
(0) » ]> 

<position ^"class* <position 2 current» 

<aerge 

.v 
<get £ 

<position 

-•"class" 
<position 2 current» 
(0)»J> 

<put .s1 [ .w -*"asserted" ]> 

Clauses are classes at their top level. For exaaple the clause 
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<clause £] [not [on a b]] [on a c]> would be stored under the 
coordinates for [not [ en a b] ] and [on a c]. Variables in expressions 
are ignored on indexing. Thus two expressions which are the same 
except for change of variables are considered eguivalent. When the 
bucket under seme coordinate exceeds a threshold then the bucket could 
be sub-aivided by taking the coordinates by pairs. The only reason 
that we don't store statements under all the possible ccmbinations of 
coordinates is that we can not afford to use that much space, storing 
the most recent assertion at the front of a bucket also tends to speed 
retrieval. If a total ordering is imposed on the assertions, then the 
buckets can be sorted. Bichard Greenblatt has constructed a clever 
total ordering on the assertions which also has the advantage of 
/""> storing new assertions at the front of the buckets. The total 

ordering is constructed incrementally as assertions are made, if 
HATCH1ESS had an efficient parallel processing capability tnen the 
retrieval could be even faster since we would do the look-ups on 
coordinates in parallel. Be might imagine a machine with multiple 
program counters each of which is capable of interrupting the 
execution of the others. However, with the current technology it 
appears more economical to timeshare a few very fast physical 
processors. Clauses are stored in a special way for efficiency. The 
value of the expression <CUBHEHT I pattern! I state-path f> is an arc 
from the state in |state-path| which contains the assertion with 
indicator name being an assertion that matches J pattern!. 



5.2 page 223 _ 

<current? 

[subset a b] 

[-"use" <has [difficulty trivial}>]> 

is true only if it has been proved that a is a subset of b with the 
value trivial under the indicator difficulty.. We shall use the prefix 
operator ?x for <GIvEH x> to denote variables of the guantificational 
calculus. The concept of a variable is different froa that of an 
identifier in that variables have global scope. 

given: 

<assert 

<put 

<clause [[<object> xj [<set> y z]] 
[subset [f ?x] ?y] 
[subset ?y lz}> _. 

[difficulty hard]» 

The above statement says that for all objects x and sets y z that £ £ 
x] is a subset of y or y is a subset of z. evaluate: 

<prog [[<set> » u] ] 
<current 

<clause [subset _w _uj <?»» 

evaluates 

to <clause 

££<object> x]] 

[subset [f ?xl £f ?x3]> 
v gets the value [f ?x] 
u gets the value [f ?x] 

<CURREMT 

| pat tern | | state-path] > is exactly like COBRIHT? 
except that if it runs out of objects that are currently in Jstate- 
path] which latch | pattern | then it generates a simple failure instead 
of returning false. The vaJue of CUBBEHT is the node which is the ""^ 
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property list of an assertion in Jstate-pathJ which matches I pattern! 
<GOAL 

Igoal-patternf irecj [-«"PITH« |state-path| ]]> tries to 
achieve the J goal- pattern i according to a reconnendation frecj. 
Beconnendations are optional; the default reconnendation is 1>"0SE» 
VCOBBEHT" <?>] which leans the data base is searched to see if there 
is soiething already proved which latches (goal- pattern} then use it 
otherwise try any consequent theoren whose consequent natches | goal- 
pattern}. The reconnendation jrecj aust be of one of the following 
two forass 

1s [-."CS1" 

-"CDBBBBBT" 

-pats-] is equivalent to 

<COID 

£<C0BBBBI? | goal-patters | J state-path |> 1 
£-"BLSB" 
<CALL 

[<£GOAl {goal-pattern | ]> 
[-."USB" -pats-] 
f state-path | ]>]> 

2s £-."0SB1" 

-."COBBBHT" 

-pats-] is equivalent to 

<COID 

£<COBBEBT? 1 goal-pattern | Istate-path J> ] 
[-"BLSB" 4 

<C«LI 

£<£GOal | goal-pattern J ]> 
[-."OSB" -pats-] 
1 state- path | ]>]> 

The -."USE1" recommendation is due to pat linston. llan Kay has 

suggested that the syntax of PLAHHBB could be easily changed so that 

^ every expressien is a goal. Thus instead of writing <GOAl x> we would 
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simply write x. Alan*s suggestion has the merit that it simplifies the 
language. One reason that we do not do this is that pattern directed 
invocations are somewhat more inefficient than straightforward calls 
in which the name of the called function is explicit. Anyone who 
prefers the other syntax can easily expand all function calls <f args> 
into <[f args]> by a trivial macro. 

Suppose that we know that zero is an integer and that if n is 
an integer then n«-l is an integer. He would like to find an integer j 
which is not zero. 

< assert [ integer ]> 

<assert <conseguent Tn] _ 
{integer [♦ ?n 1]] 
<goal [integer ?n]>» 

j gets the value £+0 1] 

<G0A1? 

| goal- pattern J |rec| [-."PATH" Jstate-pathJ ]|> is 
exactly lieke GOAL except that it returns <> instead of backtracking 
if it runs oat of alternatives. 

<GCALS> 
returns as its value a list cf the specifications of the currently 
active goals. 

<SBBGOAL 

-clauses- > attempts to natch the first element of each 
clause in turn to the elements of the list of currently active goals. 
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If the first eleaent of a clause Batches then execution continues with 
the reaaining elements of that clause. 

5.2.2 Control Primitives 

<S HITCH 

I new-state-path J ] expression | > evaluates J expression | 
using the | new-state- path! to do retrievals froa the data base. At 
any $iven tiae PLAHHE1 expressions are being evaluated in a state 
path. A top level process begins by using the priaary data base as 
its state, it can switch into a local state bj using the the function 
SIITCH. Tree structures of local states can be created by using the 
f~\ function STATEPROG. states can be conceptualized as a linear list of 
changes to the data base. Thus there can be several incompatible 
states of the world simultaneously under consideration. Although the 
tree structure of the local states can be conceptualized as a linear 
list of changes, it is actually iapleaented aore efficiently so that 
the retrieval tiae for assertions is essentially independent of the 
size and nuaber of local states. The assertions in the data base are 
tagged as to which states they are in. 

<STATB> 
returns as its value a new local state. 

<PBIHABY> 
is the priaary state of the systea« 

<DPDATE 
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I state 1 J Jstate2J> upaates Istate1| into |state2l. If 
the second argument is missing the global data bese is assumed. 
<GIT1 

|xj> is the value of \x\ unless |x| fails simply in 
Khich case it is <>. the expression Sjxi is an abbreviation for <GATE 

Ul>. 

1Kb lock (<oblist gate!-> <oblist>)> 
<define gate <f unction out [«x] 
<f ailpoint £ ] <> 

{message activation?] 
<cond 

£<nct Cor .message .activation?» 
; "neither the message nor 
activation are on" 
<.out <» 

;"exit gate with f alse" ]» 
<eval *x> 

; M the value of gate is the value of .x unless 
the evaluation of x fails» 
!X<end-block> 

<cond £-»"else" <fail>3> fails with the message <>. 

<cond £<fail> 3] [-"else" 7]> fails 

<cond £S<fail> 3] £-»"else« 7 ]> evaluates to 7. 

<cond £<> 3]> evaluates to <>• 

<cond £<> 3] £-*else" U]> evaluates to 4. 

<coad £-.«els«« <fail>] £-«else" 5]> fails. 

<cond £6-»»else« <fail>] £-«"else" 5 ]> evaluates to 5. 



<TEHEBOG 

♦checker* ♦activation-name* £ -declarations- J -body-> 
is like the function PB06 except all assertions and erasures that are 
made within the scope of the function TEHPBOG are undone when the 
function TEflPBOG returns. The function TEHPBOG is useful for dealing 
with hypothetical . Suppose that ve wanted to establish £all x £p x]j 
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b mathematical induction. 

<goal [p 0]> 

; "first try to prove [p 0]* 

<temprog [k <arbitrary <integer»] 

; w let k be an arbitrary integer » 

<assert [p . k]> 

;*assert that p holds for k" 

<goal [p !•<♦ .k 1>]> 

; «try to prove that p holds for k+1"> 

<SiITCH 

I state- path| t expression J > causes J expression J to be 
evaluated with | state- path | as its current local state path. The 
value of PATH1-STATE is the current state path* local states are 
useful for handling contra- to- factual conditionals and for 
simultaneously manipulating inconsistent states of the world. 
Assertions affect only the state which is the first element of the 
state path in vhich the assertion is evaluated. The following assigns 
the identfier s1 the value vhich is a local state path in which Hitler 
invaded England. 

<switch 

<_ :s1 [<state> !.path!-state]> 

<assert [invade Hitler England ]» 

He further suppose that Hitler is crazy. This could be expressed by 
doing the assertion within s1 and assigning the result to s2: 

<s witch 

<_ *s2 [<state> !.s1]> 
< assert [crazy Hitler ]» 

How if we ask if Hitler is cra2y in the state path s1, the answer is 
that he is not; but he is crazy in the state path s2. 
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<s witch .si <current [ crazy Hitler 3» fails 

<switch ,s2 <current [crazy Hitler ]» is true 

<switch .s2 <current [invade Hitler England ]» is true 

<switch 

[<1 .s2>] 

<current [invade Hitler England]» fails 
<switch 

[<1 .s2>] 

<curcent [crazy Hitler ]» is true 
<switch 

[<2 ,s2> <1 .s2>J 

<current [crazy Hitler ]» is true 

Erasures affect the first local state of the state path in which they 
are evaluated. After 

<s witch .si <erase [invade Hitler England ]» we have 

<switch .s1 <current [invade Hitler England ]» fails 
<s witch .s2 <current [invade Hitler England ]» fails 

/""^ If »« *now that a foraula of the fori [or |x| |y|] is true and 

we want to establish a goal of the fora Jgj then we could write: 

<PBOG [J 

<TEflPBOG [ j 

<ASSBB3 ]xl> 

<G01Z Jg|» 
<TEHPHOG [ 3 

<ASSIBT y> 

<GOAL Jg|» 
<ASSEil Jg|» 

The above fora of disjunction eliaination is often used when y is of 
the fora [HOT lx|3. Goals of the fora [or Jxj Jyj] can be established 
as follows: 

<PBOG [ 3 

<TBHPHOG [3 

<ASSEBI [MOT Jl| 3> 

<G0A1 y» 
<ASSBHT <CLA«3SE [ J |x| |y|>» 
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5.2.2.1 Failure Primitives 

<UHIQDE> fails if the current goal is not unique among all the 
goals that are currently active. 

<UHIQ0E 

<IPl -args-> Jplace|> fails if the procedure |pl with 
arguments -args- is not unique among all the procedures that are 
active in J placet. The 1 place) can be a process or it can be [BETBEEK 
|name1| Jname2|] in which case only the procedures between I name 1 J and 
|name2| are be examined. 

<RETRY 

JactivationI> causes failure to lactivaticnl which 
must include the call to RETRY within its scope. Execution resumes 
with the beginning of the named block. 

<prog here [a] 

< a 3> 

<prog there [ ] 
<cond 

£<is? ft .a> 

<.here .a> 

;"exit .here with .a w ]> 
<_ :a 4> 
<retry .there>» evaluates to 4 

5. 2*2. 2 Finalize primitives 
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<PINALIZE 

*activation-naae+> causes all actions that have been 
taken in the block ♦activation-naae* to be finalized and then returns 
the value of ♦ activation- aane*. Thus «FIBA1LIZE +activation-na«e*> - 
values-> Mill finalize all the actions that have been taken in the 
scope of +activation~nane+ and then exit +activation-naae+ with - 
values-. Actions which are finalized are not undone if a failure 
backs up. Finalization can be used to save storage for actions which 
should not be automatically reverted in case of failure, por exanple, 
robot thinking for a given task is often divided into two phasess a 
planning phase and an action chase. In PIAHBBB this is typically done 
by having the planning phase return as its value a PBOCEDU BE which is 
^-^ to be executed in the action phase. Assertions which record events 

which have taken place in the "real world" should be finalized in the 
action phase as they happen. 

5.2.2.3 Bepetition Pxiiitives 



<POB 

♦checker* +activation-naae+ [-declarations-] 
[-for-specifications- 
[-."COBBERI" Jpatternj J state-path | ]] 
-body-> 
is the for statement of PLABBEB. Por each assertion in the data base 

that latches | patters! the -body- is executed. Por exanple the 
following statement places all the bricks on brickl in the blue box. 

<for 

[£<brick> x]} 
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[[-■" cur rent" [on~top-of _x brick"!]]] 
<pick-up . x> 
<place-in <• [blue box]>» 



<PEHSIST 

♦checker*- +actiwation-naae* [-declarations-] 
[[-."I8ITIJIL" -initial- action- ] 
[-."TEST" | test J -test-action-] 
['."LIST" liteal condition] 
[-."STEP" -step-action-] 
[-."EIH1L" -final-]] 
-body-> 
where >activation-nane* and ^checker* are optional Is equivalent to 



the following: 



<PBOG ♦checker ♦ ♦activation-naae* 
[-declarations- 
[ COLLECTED () ]] 
; "initialize COLLECTED to [] 
<EAILPOIHT 

[HESS AGE aCTIVaTIOH] 
<COHD 

£<HOT? <oa? 

. HBSS6GE 
.ACTI¥ATIOl» 
-final- 

<, ♦activation- naie* 
.CCLLECTED> 
;"exit .♦activation-naBe* with 
. collected "]>> 
-body-. 
<COHD 

[I test | 

>test-*ackion- 

<» ♦activation- aaae* •COLLECTBD> 
j"a*it .♦activation-nane+ 
with .collected" ]> 
<COMD 

[| condition | 

;" if the condition is net 
then add itea 
to the end of COLLECTED" 
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<_ :CC1LECTED {!. COLLECTED iten)>l> 
-step-action- 
<P1II> 
; "generate a sinple failures 

'Are all the blocks in boxl green?" translates to 



<persist b1 [T<block> b]1 

[[-"final" <.b1 H> ;"exit .b1 with t"]] 
<goal [in _b boxt]> 
;"find a block in boxl" 
<cond 

[6<goal [green .b]> 

;"if the block is green then 

continue with the loop" ] 
[-"else" 

<£ail <> ,b1> 

; "otherwise generate a failure out of 
the persist loop"]» 



<FIHD 

♦activation- nane+ 
[-declarations- ] 

[-"Q0AHTITI Iquantityj] 
[-"LESS" I lower-bound J -fewer-] 
[-"GBIATBB" Jupper-boundl -«ore-|]] 
|itei| 
-body-> 
constructs a list of between J lower | and Jupperl Jitea|s according to 

the Jbody|. the TIED primitive function is egaiwalent to the 
following: 



<STB«IGHTEH <PHOG *actiYation-nane* 

[-declarations- [HDHBBB 0] [COLLECTED (ill 
<failpoint []<>[H] JJ 

<C0HD 
— v [<E0T? <0B? .■ .!» 



collected" ]» 
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<COHD 

[<HOT? <IS? 

Iquantityl 
-<"ALL"» 
<FM1> ]> 
;"if the quantity sought 
is not all 
then backtrack" 
<COHD 

£<IS? 

<LESS |lower-bound|> 
. NOMBER> 
-less-]> 
< . -fact ivat ion- na«e+ 
,CCLLECTED> 
;"return with the items 

-body- 

< : COLLECTED (! •COLLECTED |ite*|)> 

<IHC!-PERSISTEHT HUHBEB> 

<COND 

[<IS? Iquantityl .HUHBEB> 

<.+activation-nane+ .CCLLECTED> 
;"if have found the quantity 

desired then return then"]> 

<CCRD 

[<IS? <G BEATER J upper-bound |> . HUMBEB> 

-more- ]> 

<FAIL»> 

"Find three boxes that contain green blocks." 
translates to: 

<find ££<box> x} [<block> bj] [[-"QUANTITY" 3]] .x 
<goal [box ^x]> 
<goal [contains .x _b]> 
<goal [green .b]» 



5.2.2-1 Haiti-Process Primitives 

In more complicated situations, *e find that it is convenient 
to be able to have more than one PLAHHEB process. 
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<FAIL 

1 Message | J place | |f unction |> generates a failure with 
Jaessagej to tfce jplacej at the last joint that execution left 
I place |. if the process which called Fill is ever resuied with 
arguments, then it begins by applying JfunctionJ to the arguaents. 

<EXHAUST 

♦checker* ♦activation-naae* £ -declarations- 1 
[[-"INITIAL" -initial-action- ] J 

[-."TEST" J test | -test-action- 1 
[-"ACIION" -action-] 
[-"LIST" Jiteaj |condition|] 
[-"STEP" -step-action- J 
[-"FINAL" Jfinalljj 
-body-> 
attempts to execute -body- once for each tine that -action- is 

^ successfully evaluated. Every tiae that the body it executed the 

function EXHAUST sends a siaple failure to the action to see if it has 
any alternatives. An EXHAUST loop is very auch like a PEBSIST loop 
which is defined above. Both loops are driven by the failure 
aechanisa. Tke Bain difference is that the effects of executing the 
body of a PEBSIST loop are not preserved because a failure aust 
propagate through the body before it can be executed again, in an 
EXHAUST loop a separate process is created for the action so that the 
effects of executing the body can be preserved. The function EXHAUST 
is eguivalent to the f cllowing expression: 

<PHOG ♦checker* ♦activation- oaee* 
C 

[COLLECTED () ] 
[<proc> 

[ ACTIO B-PBCCBSS <PBOCESS , ACTIO*-? U»CTICI>] 
^ [TAL-BBOC <.1CTI0H-PB0CESS <BB0CBSS»}]3 
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;"declare COLLECTED to be initialized to [ ]" 
;"ACTICH-PROCESS is the naie of the 

process which is to be exhausted by failure" 
;"start the ELANNEB process . ACTIOfl-PROCESS in 
which the action is executed with 
the nane of this process 

as an argument so that it can later resume 
this process" 
;"we expect one value to be returned 

which we shall call VAL-PROC" 
<REPEAT [ ] 

<COND 

[<IS? EXHAUSTED .VA1-PR0O 
-final- 

<.b .COLLECTED > 
;"exit . b with .collected"] 
[ I test* 

-test-action- 

;"if the test is met 

then execute the test-action" 
<.b . COLLECTED >]> 
-body- 
<COHD 

[ | condition 1 

<. ; COLLECTED (!. COLLECTED litea|)>3> 
;"if the condition is met then add the itea to the end 

of the list of collected items" 
<PAIL 

<> 

.ACTICN-PBOCESS 

<F0HCTIOH [¥] <_ :VAI-PBOC .Y>» 

; "suspend 

execution of the current process 

and begin failing from the point within 

the action process 

where execution last left off"» 

The following function is defined so that we can start off the 
evaluation of the action process, 

<DEFIHE ACTIOH-FONCTIOti 

[FUNCTIOH ££<proc> HAIH]] 

<FAILIHG? [<?> <.HAIN EXHAUSTEO ]> 
;"when the action finally is exhauseted 

resume the process .HAIR with the value EXHAUSTED and 
terminate the action process" 
-action- 
<.(UIN SUCCESS> 
;"resume the main process nith the value SUCCESS" ]> 
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Suppose that we want tc disprove a proposition .p using likely 
counterexamples. Furthermore we would like to work on each 
counterexample in parallel as it is found. 

<exhaust disprove [c] 

<goal [ likely-counter-example _c .p]> 
^|<ccnd ~ 

[6<goal .c> 

<teaporize 

♦disprove> 

-* ,f f ound-counter-example»» ]» 
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5.3 Clauses in PLAHHEB 



Be would like to explore the potentialities for using PLAHHEB 
to control a resolution based deductive system. Since the question 
whether or not a given formula is a theorem or not is undecidable, a 
complete proof procedure using resolution for the first order 
quantificational calculus must in general be rather inefficient. In 
fact any uniform proof .procedure for the first order quantificational 
calculus can be sped up by an arbitrary recursive function for almost 
all proofs. The result on the necessary inefficiency of a complete 
proof procedure should be sharpened up. Hew theoretical tools must be 
developed in order to make any substantial advance on the problem. 
The importance of resolution as a problem solving technique does not 
lie in the fact that it appears to be the fastest known uniform proof 
procedure for first order logic. Bather, resolution provides one 
technique for dealing with the logic of disjunction and instantiation. 
Domain dependent procedures must provide most of the direction in the 
computation to attempt to prove a theorem, fe shall introduce new 
actors to match clauses: 

<CLA0SB 

-patterns- |rest-of-dis junctsl> matches a clause only 
if it has dis jnncts which match -patterns- and the rest of the 
disjuncts match the pattern J res t-of -disjunct* J. 
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<prog £y] 

<clause [subset a :yj> 
<clause [x] [subset ?x bl>» 

y gets the value b 

x gets the value a 

<CLA0S£-OF 

Jpatf |disjuncts-that-watch-patj lrest-of-disjuncts|> 
matches a clause such that the clause of the disjurcts that Match 
Jpatj in turn natch the pattern |disjuncts-that-aatch-patj andthe 
clause of the the rest of the disjuncts natch Irest-of-disjunctsJ. 

The following functions are used to aasipulate clauses. 

<CLAOSE 

[-declarations-] -disjuncts-> returns a copy of a 
clause nith the variables declared. 

<YABIABLBS 

(clause l> returns the variables in the clause. 
<IHSTANTIATE 

jclause|> returns a copy of the clause with all of its 
variables instantiated with unique constants of the appropriate type. 
<BESOL»E 

-clause-specifications- > results in resolving the 
clauses represented by the clause specifications together to yield a 
clause which is returned as the value of the function resolve. A 
clause specification is the literal of the clause which is to be 
unified. 
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<FOB-BESOL¥EHT . . 

♦checker* ♦activation-name* [-declarations- ] 
[[-»" CLAUSES" -clause-specifications-] 
£-»"BESOLVEHT" J resolvent | ] 
-f or-loop-specifications- ] 
-body-> 
attempts to execute the body of the for statement once for each result 

of resolving clauses that meet the clause specifications to produce a 
clause which aatches the pattern resolvent. 

It is possible for PLAHNEB to run out of things to evaluate 
before it has deduced the null clause. A coiplete proof procedure 
could be called to try to finish off the proof. If in the course of 
its operation, the complete procedure generates a clause that latches 
the antecedent of a theorea then PLABHEB can be re-invoked. The 
complete procedure could be run in parallel with PLAHHEB. Thus using 
PLAN BEE we could implement a conplete proof procedure. The point is 
that implementing any "reasonable" proof procedure should be easy in 
PLAHNEB. However, we should not rely on a uniform proof procedure to 
solve our problems for us. 
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5.4 A Simple Example 



5.4.1 Using a Conseguent Theorem 

Suppose that we know that [subset a b], [subset a d ], [subset 
b c] # and [all [function <bccle> [[<set> x] [<set> y] [<set> z]] 
[implies [and [subset ?x ?y] [subset ?y ?z]] [subset ?x ?.z]']]] are 
true. How can we get PLA8NE8 to prove that [subset a c] holds? We 
would give the system the following theorems. 



gxven: 

[subset a b] 
[subset ad] 
[subset be] 

<assert <define backward _ m % 4 ^ ^ , 

<conseguent [[<set> x y z]] [subset ?x ?z] 

<unigue> 

; w the current goal must be unique" 

<goal 

[subset ?x ?y] 

[^•"use" -^"current* backward <?>]> 
<goal 

[subset .y ?z] 

[-•"use" -^current* backward ]> 
<assert [subset *x .z] [-i"try" <?>]»» 

Now if we ask ELANNEB to evaluate <goal [subset a c]> then we obtain 
the following protocol: 
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<goal [subset a c]> 

<current [subset a c]> 

fail 

<achieve [subset a c ]> 

enter backward 

x becomes a 

z becomes c 

<unique> 

<goal [subset a ?y ]> 

<current [subset a ?y ]> 
node 1,9 

y becomes d 

<goal [subset d c]> 

<current [subset d c ]> 

fail 

<achieve [subset d c ]> 

enter backward 

x becomes d 

z becomes c 

<unigue> 

<goal [subset d ?y]> 

<current [subset d ?y ]> 
fail 

<achieve [subset d ?y ]> 
/"""N enter backward 

x becomes d 
z becomes ?y 
<unique> 
fail 
fail 
node 1,9 ;note that this node appears above 
y becomes b 
<goal [subset b c]> 

<current [subset b c]> 
<assert [subset a c]> 
succeed 

After the evaluation the data base contains: 
[subset a b] 

[subset ad] 

[subset be] 

[subset a c] 

In other words the first thing that PLAflHEB does is to leck for a 
theorem that it can activate to work on the goal* It finds backward 
and binds x to a and z to c. Then it makes [subset a ?y] a subgoal 
^**\ with the recommendation that backward should be used first to try to 
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achieve the subgoal. The system notices that y night be d # so it 
binds y to d. Hext [subset d c ] is made a subgoal with the 
recommendation that culy backward be used to try to achieve it. Thus 
backward is called recursively, x is bound to d # and z is bound tn c. 
The subgoal [subset d ?y ] is established causing backward to again be 
called recursively with x bound to d and z determined to be the same 
as what the old value of y ever turns out to be. Bat now the system 
finds that it is in trouble because the new subgoal [subset d ?y] is 
the same as a subgoal on which it is already working. So it decides 
that it was a mistake to try to prove [subset d c] in the first place. 
Thus y is bound to b instead of d. Now the system sets up the subgoal 
[subset be] which is established immediately. He use the above 
example only to show how the rules of the language work in a trivial 
case* If we were seriously interested in proving theorems in PXANHBH 
about the lattice of sets, then we would construct a finite lattice as 
a model and use it to guide us in finding the proof. 

5.4.2 Osiag an Antecedent Theorem 

Suppose we give PLAHHER only the following theorems. 



gxven: 

[subset a b] 

[subset c d] 

<assert <define forward-right 

Antecedent [[<set? t y z]] [subset _y _z] 

<goal (subset ?x .t]> 

<assert 



5.4 page 244 

[subset .x .2] 

[-«try" forward-right forward-left ]»» 

<assert <define forward-left 

Antecedent £[<set> i y z]] [subset _x y] 
<goal [subset ?y . z]> ~ ~ 

<assert 

[subset .x .z] 

[~.«try* forward-right forward-left ]»» 
How if PLASBEB is asked to the theorem evaluate <assert [subset be] 

[-•"try" <?>]>, we ottain the following protocol: 

<assert [subset b c]> 

<draw [subset k c ]> 

enter forward-right 

y becomes b 

z becoies c 

<goal [subset ?x b]> 

<current [subset ?x b ]> 
x becomes a 
< assert [subset a c]> 

<draw [subset a c]> 
/**\ enter forward-right 

y becomes a 
z becomes c 
<goal [subset ?x a]> 

<current [subset ?x a ]> 
fail 
enter forward-left 
x becomes a 
z becomes c 
<goal [subset c ?z ]> 

<proved [subset c ?z]> 
z becomes d 
<assert [subset a d]> 

<draw [subset a d]> 

enter forward-right 

y becomes a 

z becomes d 

<goal [subset ?x a]> 

<current [subset ?x a]> 
fail 
enter forward- left 
x becomes a 
y becomes d 
<goal [subset d ?z]> 

<current [subset d ?z]> 
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fail 



succeed 



After the evaluation the data base contains; 
(subset a b] 
[subset c d] 
[subset ad] 
[subset be] 
[subset a c] 

Theorems in FLANBEB can be proved in much the same way used 

for ordinary theorems. For example suppose that we had the following 

two theorems: 

<assert <define th4 <conseguent [(<set> a c]] [subset ?a ?c] 
<goal [set ?a]> 

<temprog ([<object> [x <arbitrary <object»]j] 
<assert [element .x .a] <?» 
<goal [element .x ?c ]» 
<assert [subset .a .c] <?>»» 

The function AEBITRABY generates a unique symbol which has the type of 

its argument* On entrance to the function TEHPROG the identifier x is 

bound to a freshly created symbol* The above theorem is a 

constructive analogue of 

[all [function <boole>[[<set> a] (<set> c]] 
[implies 

(all [function 
<boole> 

[[<object> x]] 

[implies [element ?x ?a][ element ?x ?c]]] 
[subset ?a ?c]]]]] 

Going in the opposite direction, we have 

<assert <def ine th4-5 Antecedent 
[[<set> a b]] 
[subset a b] 
<assert 

<antecedent 

[[<element> x]] 



/**% 
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[eleaent ?x ?a ] 

<assert [eleaent ?x ?b ] <?» a>»» 

<assert <define th4-6 Antecedent 
[[<set> a b]] 
[subset a b] 
<assert 

<conseguent 

[[<eleaent> x]] 
[element ?x ?b] 
<goal [element ?x ?a}> b>»» 

<assert <define 
th3 

Consequent [[<object> xj[<set> r s]] 

[eleaeat ?x ?s] 
<goal [eleaent ?x ?r]> 
<goal [subset ?r ?s]> 
<assert [eleaent .x ,s] <?>»» 
The above theorea is a constructive analogue for 

[all [function 
<boole> 
f~\ [[<object> x] [<set> s]] 

[ iaplies 

[soae [function 
<boole> 
[[<set> r]] 

[and [eleaent ?x ?r] [subset ?r ?al]1 
[eleaent ?x ?s]]]]] 

Fron th3 and th3 we can prove the following theorea: 

Consequent [[<set> a b cl] [subset ?a ?c] 
<goal [subset ?a ?B]> J 

<goal [subset .b ?c]> 
<assext [subset .a ,c] <?>» 

The above theorea is a constructive analogue for 

[all [function 
<boole> 

[£<set> a] [<set> bj [<set> c]] 
[ iaplies 

[and [subset ?a ?b] [subset ?b ?c]l 

[subset ?a 7c}]]] 
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Oftea we treat the statement of a theorea siaply as an abbreviation 

for the proof of the theorea. 

He would like to exaaine the previous problea froa the point 
of view of resolution based deductive systea. The actor CLAUSE aatchs 
clauses. It uses the fact that disjunction is coaautative and 
associative. He haves 

U <clause [[<set> a b] f<object> x]] 
[not [subset ?a ?b]3 
[not [eleaent ?x ?a]] 
[eleaent ?x ?b ]> 

2 ' <Cia £ U ?!e.int e [ell«ent , -of-difference ?a ?bl ?a] 
[subset ?a ?b]> 

3. <clan ^J[<f|*> n J [Jieaent-of-difference ?a ?b] ?b]3 
[subset ?a ?b]> 

<assert <define necessary 
Antecedent 

[literal! Iiteral2] 

<clause <all [subset (?) 3 _literal1> <?» 
<_ 
~ <clause 

<all 

[not [subset (?) ]] 
_literal2> 
<?» 
<clause [[<set> an] [<object> x]] 
[not [subset .a .b]J 
[not [eleaent ?x .a]] 
[eleaent ?x .b]» 
<assert <resol*e .lite rail .literal2>»» 

The above theorea says that we should eliainate all positive instances 
of the predicate subset froa clauses. It is a special case of 
theoreal which has been partially compiled. 
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<assert <define sufficient 
<antecedent 

[[<set> a b] liter all ] 

<clause <all [not [subset a bjj literal 1> <?» 

<prog [literal2J ~ 

<clause <all [subset {?} ] literal2> <?» 
<clause [[<set> a b]] 

[subset .a .b] 

[eleaent 

[eleaent-of -difference .a .b] 
.a]» J 

<assert <resolve .literall . liter al2>» 

<prog [literal2] 

<clause <all [subset {?} ] literal2> <?» 

<clause [[<set> a b]] 
[subset .a .b] 
[not [eleaent 

[eleaent~of -difference .a .bl 
• bJ3» 
<assert <resolve . literall . liter al2»>.»> 

^ The above theorea says that He should eliainate all negative instances 
of the predicate subset froa clauses. 



5.4.3 Using flesolution 

»e shall assuae that the resolution routines autcnatically 
detect contradictory pairs of clauses ahen they are generated. The 
theorea [iaplies [and [subset a b] [subset b c]] [subset a c]] can oe 
proved as follows: 

<prog [ J 

<teaprog [(<set> 

[a < arbitrary <set»] 
[b <arbitrarv <set»3 
[c <arbitrary <set»]33 
<assert <clause [3 [subset .a .bj> [-."try" <?>!> 
<assert <clause [3 [subset .b .c3> [■'"try" <?>]> 
/■^ <assert <clause £ J [not £subset .*» .c]3> [-"try" <?>3> 
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<goal <clause»> 
<assert <clause [[<set> x y z]] 

[not [subset ?x ?y]J 
[not [subset ?y ?z]} 
[subset ?i ?z]>» 



The proof is: 

iset a b]> 
5. <cl*«f!J ot t[aS««t 3 ix aj] [element ?x b]> by 1. and 4, 



4. <clause [ ] 
[sub~ 



6. <clause [ ] t 

[subset b c]> 

7. < clau ^ e t [ I < e!lie^ 3 ?x b]] [element ?x c]> by 1. and 6. 

8. <clause [ ] „^ 

[not [subset a c]]> 

9. <clau ^| 1 ^J eDt [eieaent-of-difference a c] a]> by 8. and 2. 

10. <claQ *f e y nt [elenent-of-difference a c] b]> bv 8. and 3. 

11. < cla fs« t C c 3 eieaea1 . [ele «ent-of-difference a c] c]]> by 10. and 7. 

12. ^a^J^^ent [eleaent-of-difference a c] b]]> by 9. and 5. 

13. <clause [ ]> by 12. and 10. 
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5.5 Hyths about PL1NNEE 



5.5.1 Conseguent Theorems Are Used Only for Working Backwards 

We would like to give an example to show that the computation 
tree that El&MNEH defines as it executes theorems does not necessarily 
correspond to the tree of the intuitive solution space which is being 
investigated. The example which we use is the farmer, goat, cabbage, 
and wolf problem. We worked out the following solution with Jeff 
Rulifson. The problem begins with a farmer on the side of a stream 
with a boat, a wolf, a goat, and cabbage. The farmer wants to 
^ transport them all across the stream in the boat. The boat can only 
hold one of them besides the farmer. The wolf will eat the goat and 
the goat will eat the cabbage if the farmer is not there to interfere. 
How can the farmer get them all across the stream? He begin by 
evaluating <goal [frcm t t t t]> which means to set up a goal to make 
a move from the postion where all four objects are on the same side of 
the tank. 

<assert <define make-move <conseguent make 

[wolf goat cabbage farmer] 
[from ?volf ?goat ? cabbage ?faraer] 
<goal [safe .wolf .goat .cabbage . farmer ]> 
;"aake sure the current situation is safe" 
<cond 

[<and? 

<is? <> ,wolf> 
<is? <> .goat> 
<is? <> .cabbage> 
<is? <> .farmer» 
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<«aake t> 

;*exi* .Bake with t" ]> 
;"if they are all safely on the other 

side of the river return t" 
<cond 

[<current? [look^d-at 

• wolf 

• goat 
•cabbage 
•f araer ]> 

<»aake <» 

;«exit .make with <>«]> 
;*if we have already looked at this situation 

return <> which is false" 
<assert [looked-at .wolf .goat • cabbage .f araer ]> 

<or 

6<cond 

[<is? *f araer .goat> 

;*if the fara^r is on the saae side 
as the goat, 

then he can carry the goat with 
hia to the other side" 
<goal [froa 

• wolf 

<not? *goat> 
•cabbage 

<not? .faraer>l>3> 
6<goal [froa 

• wolf 

• goat 
•catbage 

<not? •faraer>]> 
6<cond 

r<is? .f araer *wolf> 

;«siailarly if the faraer is on the saae side 

as the wolf " 
<goal [froa 

<not? *«olf> 

• goat 
•cabbage 

<not? •faraer>3>]> 
&<cond 

[<is? *f araer •cabtage> 
<goal [froa 

• wolf 

• goat 

<not? •cabbage> 
<not? » f araer> J> ]» 
;«the function OR txies the 

possibilities in order>» 
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<assert <define safety-check <consequent safety-check 

[wolf goat cabbage faraer] 
[safe ?volf ?gcat ? ?farwer] 
<cond 

[<or? 

<and? 



<and? 



<is? .wolf <not? .faraer» 
<is? .wolf ,goat» 



<is? .goat <not? . farmer » 
<is? .goat .cabl>age>» 
;"the situation is not safe if either 

the wolf is on the opposite side 
from the faraer 

but on the saae side as the goat or 
the goat is on the opposite side froa the 
faraer bat on the saae side as the cabbage" 
<fail <> .safety-check>]»» 
The protocol of the solution is: 

<goal [froa t t t t]> 

<goal [froa tot <>]> goat 
S~\ <goal [froa t t t t]> goat 

<goal [froa t <> t t]> hiaself 

<goal [froa t <> t <>]> hiaself 
<goal [frca <> <> t <>]> wclf 
<goal [froa <> t t t]> goat 

<goal [frca <> <> t <>]> goat 
<goal [froa <> t t <>]> hiaself 
<goal [froa <> t t t]> hiaself 
<goal [froa t t t t]> wolf 
<goai [frca <> t <> <>J> cabbage 
<goal [froa <> t <> t ]> hiaself 

<goal [froa <> <> <> <>]> goat 

Hote that there are several things wrong with the above procedure. 
For one thing the problea solver should work forwards and backwards 
siaultaneously trying to find necessary conditions for a solution as 
well as sufficient condtions. The procedure is not very saart in the 
way that it goes about looking for a solution. These ills can be 
cured in various ways. The reader aight find it instructive to 
^^ consider soae of the possibilities. 



5.5 page 253 

5.5.2 PLANHEB Does only Depth First Search 

PLAHNEB runs under a backtrack control structure. Because of 
the control structure the execution tree of a process locks like a 
depth first investigation. However, by creating more processes the 
growth of the set of execution trees can be quite arbitrary. As an 
example we can convert the above solution to the farmer, goat, 
cabbage, and wclf problem to breadth first investigation by evaluating 
the arguments to OH in parallel instead of sequentially in the theorem 
HAKE-HOVE. 

5.5.3 use of Failure Implies Inefficient Search 

The failure primitive in PLABHEB is a method of transferring 
control. The concept does not have any necessary relation to program 
errors such as dividing by zero. Often a proof by contradiction is 
completed by generating a failure back to an label function with a 
message like "happiness" when the contradiction is detected. The 
message is caught when it propagates back to the point where the proof 
by contradiction was set up. The effect of the failure is to get rid 
of all the garbage that is generated in the proof by contradiction. 
In a similar vein the failure mechanism is often used as a summarizing 
mechanism. At certain points along the computation, certain 
conclusions are derived from the process of investigation. These 
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conclusions can be lifted cot of the details that Here used to derive 
thea by failing back with values which summarize what has been 
learned. Then the computation can continue with a cleaner slate. 
For example in a chess program, exploration of the possible moves 
might reveal that our queen is pinned against our king threatening the 
loss of the queen. Information to that effect would be passed back 
with the failure. 

5.5.4 JPLAHNEfi Does Only what It Is Told 

In a strict sense PLABNEB does only what it is told to do. 
There is no random element or independent consciousness built into the 
f~\ primitives. However, because of the goal oriented nature of the 

formalism it is very difficult to predict what a large body of PtARHEH 
theorems will do. In fact one of the more obnoxious things that can 
happen is that some theorems find a nonobvious way to accomplish a 
trivial goal. Usually this happens because there is a bug in the code 
for the obvious way to achieve the goal. 
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6. Here on PLANNER 



6.1 PLAHHEB EXAflPLES 



6.1.1 London f s Bridge 

Host of the time we decide which statements we want to erase 

on the basis of the justifications of the statements. If we erase 

statement a f and statement b depends on statement a because a is part 

of the justification of b # then we probably want to erase statement b. 

Sometimes a decision is made on the basis of other criteria. For 

example suppose that we carefully remove the bottom brick from a 

column of bricks* We shall suppose that each brick is of unxt length. 

The statement [at | brick J Jplacej J height | ] will be defined to mean 

that brick ibrickj is at place IplaceJ at the height fheightj. 

Suppose that have the following theorems: 

[at brick 1 here 01 
[at brick 2 here 1] 

[at brick3 here 2] 

<define london's-bridge 
<e rasing 

[<brick> brick other-brick) 
[<place> place] 
[<integer> height]] 
[at _brick _place ^height] 
<erase 



s~\ 



/■"^ 



/*""*N 
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[at 

_other-brick 
• place 

<add1 . height >] 
[-•use-. <?>]> 
; "erase the fact that there is another brick 

in the place above brick" 
<assert 

[at .other-brick .place . height ]> 
; "assert that it is where 

brick used to be<*» 

Thus after < erase [at brick! here 0]> we will have [at brick2 here 0] 
and [at brickj here 1]. The upper bricks in the tower have all fallen 
down one level. The above exaaple coaes froi a suggestion aade by S. 
Pa pert. 

6.1.2 Analogies 

6.1.2.1 Siaple Analogies 

Our next exaaple illustrates the usefulness of the pattern 
directed deductive systea that PLAHHEH uses coapared with the 
quantification al calculus of order oaega. ie are interested in siaple 
analogies such as those exflored by Toa Evans. Given that object a1 
has some rexation to object a2 and that object d has the saae 
relation to object c2, tne problea is to deduce that al is analogous 
to c1. He use the predicate test-analogons within the taeorea pair to 
record that we think two objects aight be analogous and that we would 
like to check it out. Suppose that we give PIAH8BB the following 
theoreas: 
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[inside al a2] 
[inside d c2] 
[a-object a1 ] 
[a-object a2] 
[c-object d] 
[c-object c2] 

<define pair <conseguent pair 

[<object> a c] 
[<functor> predicate] 
[ {?} argsal argsa2 argsd argsc2]] 
[analogous ?a ?c ?predicate] 
<unigue> 

;"the current goal must be unigue M 
<cond 

[<current? [test-analogous ?a ?c]> 

; w if a and c are test-analogous then 

we are done 11 
<*pair done> 

; n exit .pair with done" ]> 
<current [a-object ?a]> 
<current [c-object ?c]> 
; w find an a-object and a c-object 11 
<assert [test-analogous *a ,c ?predicate]> 
Xcurrent [ ?predicate !_argsa1 .a !_argsa2]> 
<current [.predicate !_argsd ,c !_argsc2J> 
; f, find a predicate in which both a and 

c are arguaents" 
<cond 

[<is? <non [ ]> • argsal > 

<goal [ corresponding-analogous 
•argsal 
.argsd 

• predicate ]> ]> 
<cond 

[<is? <non [ ]> «argsa2> 

<gcal [corresponding-analogous 
•argsa2 
.argsc2 
# predicate ]>]> 
^show that the other arguments are analogous 11 
<assert [analogous .a. .c •predicate]>» 



<define chop-of f-another <conseguent 

C 

[<object> a b] 

[ {?} aa bb ] 
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[<functor <?> <?» predicate]] 
[corresponding-analogous [?a ??aa] [ ?c ??cc] ?predicate ] 
<cond 

[<current? [test-analogous ?a ?c ?predicate]> 

; M if a and c are currently test-analogous then 
we onlj have to look at 
the rest of the elenents" ] 
[-•"else" 

<current [analogous ?a ?c ?predicate ]> ]> 
<ccnd 

[<is? <non [ ]> .aa> 

<current [corresponding-analogous 

?aa 
?cc 
?predicate]>]>» 

Thus if we ask PLANNEB to evaluate <goal [analogous a1 ?x inside ]> 
then x will be bound to d in accordance with the following protocol: 



<goal [analogous a1 ?x inside ]> 

enter pair 

a gets the value a1 

c gets the value ?x 

predicate gets the value inside 

<unigue> 

<current [test-analogous a1 ?c inside ]> 
FAIL 

<current [a-object a1]> 

<current [c-cbject ?c]> 
node 1 

c gets the value c2 
x gets the value c2 

<te»porary [test-analogous al c2 inside J> 

<current [inside a1 a2]> 

<current [inside cl c2]> 

<goal [corresponding-analogous [a2] [] inside 1> 
enter chop-off -another 
PAIL 

FAIL 
node 1; note that this node appears above 

c gets the value d 
x gets the value d 

<te*porary [test-analogous a1 d inside ]> 

<current [inside d c2]> 

<goal [corresponding-analogous [a2] [c2] inside ]> 
enter chop-off-an*ther 
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a gets the value a2 
c gets the value c2 

<current [test-analogous 

a2 
c2 

inside ]> 
FAIL 
<current [analogous a2 c2]> 
enter pair 
a gets the value a2 
c gets the value c2 
<unique> 

<current [test-analogous 

a2 
c2 

inside ]> 
FAIL 
<current [a-object a2]> 
<current [c-object c2]> 

<teaporary [test-analogous a2 c2 inside ]> 
<current [inside a1 a2]> 
<current [inside d c2 ]> 
<gcal [correspoinding-analogous 

[a1J 
[d] 

inside ]> 
enter chop-off -another 
a gets the value a1 
c gets the value d 
<current [test-analogous a1 c1]> 
succeed 

In the process of carrying out the evaluation the following additional 
facts will be established: [analogous a1 d inside] and [analogous a2 
c2 inside]. The reader night find it aausing to try to fornulat* the 
above problem in the first order quantificational calculus. 



6.1.2*2 Structural Analogies 

The process of finding analogous proofs and nethods plays a 
very important role in theoren proving. For example the proofs of the 
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uniqueness of the identity element and inverses in semi-groups ace 
closely related. The definitions are: 

[equivalent [identity e3 [egual [* a e] [* e a] a]] 

[implies [identity e] [equivalent [inverse b1 b] [equal [* bl b] [* b 
*>1 ] e U] 1 £ e aiQ d e# are identities, then we have [equal e [* e e f ] 
e f ]• If a1 and a1 f are inverses of a # then we have [equal a1 [* a1 f 
a a1] a1]. The general form of the analogy is [equal w ^string w 9 J 
where .string algebraicly simplifies to w and w». in many cases 
analogies are found by construction. That is the problen solver looks 
around for problems that sight be solved with an analogous technique. 
In other words we will have a method of solution in search of a 
/**% problen that it can solve! Vow that we have found a technique for 

proving that various kinds of elements are unique, let us look around 
for a similar problen to which our technique applies. Me find that 
zeros in semi-groups are defined as follows: 

[equivalent [zero z] [equal £*az]£*za]z]] Supposing that z and 
z' are zeros we find that [equal z [* z z § ] z § ]. Cue major problem in 
the effective use of analogies in order to solve problems is that it 
is very difficult to decide when and at what level of detail to try 
for an analogy. Another problem is that often the analogy holds only 
at a quite abstract level and it must not be pushed too far. Consider 
the following two algorithms: 

<define nunber-of- atoms 
[function [x] 
<cond 
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[<e»pty? .x> 

0] 
[<is? !*atca .x> 

1] 
[^"eise" 
<♦ 

<nunber-of-atoas <1 *x» 
<nu*ber-o£-atoas <rest *x»>]>]> 

<define list-of-ato»s 
[function [x ] 
<cond 

[<enpty? .x> 

[J] 
[<is? !-atca *x> 

[-•"else* 

<append 

<list-of -a tons <1 *x» 
<list-of-ato«s <rest .x>»]>]> 

The functions nuaber-of-atoas and list-of-atcas ar€ precisely 
analogous* In most cases tvo functions will not be nearly so 
sinilar. Very fen of the ideas of one Mill be used in the other* 
Structural analogies lay also be constructed by procedural abstraction 
[see chapter 7]# Bledsoe has suggested that still another exanple of 
analogous proofs is found in the Schwartz ineguality: 



<non decreasing 
<expt 



<* 



2> 



<* <x 1> <y 1» 
<* <x 2> <y 2>» 



<expt <x 1> 2> 

<-* <x 2> 2» 

<-* <y 1> 2> 

<-* <y 2> 2»» 



/"**\ 



<nodccreasing 
<expt 



<* 



<s ig aa 



2> 

<sigaa 



<sigaa 
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1 
n 
<£unction 

Ci] 

<expt <* <x .i> <y ,i» 2>» 



1 
n 
<f unction 

[i] 

<expt <x ,i> 2>» 

1 
n 
<f auction 

Ci] 

<expt <y ,i> 2>»» 



f~^ 



<non decreasing 

<expt <integral <* x y» 2> 
<* 

<integral <expt f 2» 
<integral <-» g 2»» 



6.1.3 Bathenatical Induction 

He can fonulate the principle of aathenatical induction for 
the integers in the following nay: 

<define induction <ccnseguent [p] 
[for-all _p] 

<teaprog [[n <arbitrary <integer»]J 
<goal i»<.p 0» 
<assert !'<.p ,n» 
<goal !«<.p !•<♦ .a 1»» 
<assert £for-ail .p]>» 



/-N 
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If we are given the facts [« <♦ P 0> 0] and 

<clause [x y] 

<♦ ?y <♦ ?x 1» 
<♦ <♦ ?y ?x> 1>]> 

then we can establish 

[for-all <f unction [n] |> <♦ ?n> ?n]>]. 

The following theocea will do induction on s-expressions: 

<def ine expr-inducticn 
<consequent 

CP] 
[for-all _p] 

<tei»prog 

[[a <arbitary <atoa»]] 

<goal ! f <*p .a»> 

<te»prcg 

[ 

[car <arb±trary <expr»] 
[cdr <arbitrary <expr»]] 
<assert ! f <.p .car» 
<assert ! f <#p .cdr» 
<goal ! f <.p !«<cons .car . cdr»» 
<assert [for-all •?]»> 

He would like to try to do without existential quantifiers. He can 

eliminate the* in favor of Stolen functions in assertions and in favor 
of PLAHHBB identifiers in goals. The problen of finding proofs by 
induction is for sally identical to the problen of syntesizing programs 
out of "canned loops". The process of procedural abstraction [which 
is explained in chapter 7] has an analogue which is "induction 
abstraction" [finding proofs by induction frca exatple proofs written 



/*> 
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out in full without induction]. 

6*1.4 Descriptions 

6 . 1.1.1 Structural Descriptions 

PLAHHEB can be used to find objects froa partial or schematic 
descriptions. The statement [perpendicular [line _a _b ] [line jc 
_d]] will be defined tc mean that the lines [line .a .b] and [line .c 
.d] are perpendicular. The HATCHLESS function <ASSIGHED? arg> tests 
to see if the identifier arg has a value. Be shall adopt the 
convention that [glued a bj leans that bricks a and b are glued 
together and [orthogonal [line la| 1 Ji] ] [line |cj fdj]] aeans that the 
lines between the centers of bricks 1 a | and jb| is orthoganal to the 
line between the centers of bricks |c| and |dj. A three-corner is 
defined to be a group of three bricks joined together such that two of 
then are diagonal to each other. A three-corner is shown in figure 1. 
In other ;*ords the following is a description of a three-corner: 

<define find-three-corner 
< con sequent 

£[<brick> aDc]] 
[three-corner ?a ?b ?c] 
<goal [glued 7a 7b]> 
<prog again [ ] 

<goal [glued 

.a 

<all <non .b> ?c>]> 
<goal [orthogonal [line .a .b] [line .a *c]]> 
<cond 
[<cr? 

S<goal [glued 





/, :/* 
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A Three 



Corner! 




[cube 13 


Cglued 1 23 


[cube 21 


[glued 2 33 


[cube 31 
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A STICK 



[cube 4 3 
Ccube 53 
[cube 6] 
[cube 73 



[glued 4 53 
[glued 5 63 
[glued 6 73 
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/./io 
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ANOTHER STICK*, 
[cube 83 
[cube 93 
Ccube 103 



[glued 8 93 
Cglued 9 103 
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• a 

<all <non .b> <non .c»]> 
8<goal [glued .b <non .a>]> 
S<goal [glued m c <non .a>]>> 
<fall <> again>]»» 

The description can be used in the obvious way to find three-corners • 
The statement [stick _a _b ] is defined to mean that .a and .b are end 
bricks of a line of bricks and [between _a _b _c] is defined to mean 
that brick ,b is between bricks .a and .c. Examples of sticks are 
shown are shown in figure 1. 

<define find-stick 

<conseguent 

[[<brick> a b] [!*fix n]] 
[stick ?a ?b _n] 

<current [brick ?a]> 
<current [brick ?b]> 
^^ <goal [stick-segment .a .b <- . o 2>]> 

r <assert [stick .a .b .a]>» 

<define fimd-stick-segment 
<consequent find 
[[<brick> x y w][!*fix n]] 
[stick-segment ?x ?y _nj 
<cond 

[<is? <neg> *n> 

<f ail> ] 
[6<goal [glued ?v ?x ]> 
<goal [orthogonal 

[line .x .w] 
[line .x ?y]]> 
<fail>] 
[£<goal [glued ?x ?y]> 
<cond 

[<and? 

<goal [glued ?w ?y]> 
<goal [orthogonal 

[line .y .¥] 
[line .y .x]]» 
<fail>]> 
<.fimd t> 

;«exit .find with t"]> 
<goal [glued 7w #x]> 
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<goal [between .x .w .y]> 
<goal 

[stick-segment .w .y <- .n 1>] 

[-•use^ find-stick-segment <?>]>» 

6.1,4,2 Constructing Examples of Descriptions 

Given a description of a structure [such as a stick] we would 
like to be able to derive a general sethod for building the structure* 
The problem of deriving such general construction sethods f*ros 
descriptions is very difficult « In this case we we can construct a 
stick of length n with ends x and y asing the functions <GLOB facel 
face2> which glues the value of facel to the value of face2 and the 
function new-brick which produces a new brick. 

<define sake-stick <consequent lake 
[[<brick> x y wj [ !=f ix a]] 
[sake-stick _x _y _n] 
<cond 

[<is? <less 3> .a> 

<glue [bot*os .x] [top .y]> 
<.sake t> 

;"exit .take with t"]> 
<is _w <aew-brick» 
<glue [bottos .x] (top • *]> 
<goal [sake-stick _w _y C- n 1>]>» 

6, 1.4*3 Descriptions of Scenes 

S» Paper t has suggested that theorea proving techniques sight 
be applied to the prcblet of analyzing 2-disensiosal projections of 3- 
disessional bricks. In this section we *ill give a f orsal definition 
of the probles. ldolpho Guzsan has developed a progras [called SEE] 
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which tries to solve such problems. Ban; humans solve such problems 
by mentally constructing a symbolic 3-diaensional scene which 
optically projects back to the given 2-diaensional input* He define a 
brick to be a connected open opaque region of 3- space bounded by a 
finite number of planes such that if two planes intersect then they 
nust be orthogonal* Furthermore, the complement of a brick is 
required to be connected* Thus bricks are allotted to have holes in 
them* k 3-dimensional scene is an arrangement of bricks such that no 
tvo of them intersect* k 2-dinensional scene is a collection of 
straight lines in a plane* k 2-dinensiomal projection is the optical 
projection of a 3-dimensional scene onto a plane* k statement p about 
3- dimensional scenes mill be said to be valid for a 2-dinensional 
/**\ scene r if for all 3-dinensicnal scenes t such that t projects to r it 
is the case that p is true for t. k two dimensional scene rO will be 
said to be ambiguous for a language 1 if it is the projection of two 
3-dimensional scenes t1 and t2 such that there is a sentence pO in 1 
with pO true i» t1 and false in t2. There are a number of primitive 
predicates that should be included in a language for scene analysis: 

[parallel i y] means that m and y are parallel* 

[coplanar x j) means that x aad y are coplanar. 

[normal plane! directed- linesegment ] means that the normal of 
planel is in the direction of the directed-linesegaeat* 

[restricted planel pt1 pt2 pt3 ] means that the normal to 
planel is restricted to the angle ptl pt2 pt3. 

[sape-brick region 1 region2] means that regionl and region2 
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are part of the same brick* 

[adjacent region 1 region2] means that region 1 and region2 are 
regions of the saae brick that intersect at right angles. 

[convex region 1 region2] leans that region 1 and region2 are 
regions of the same brick that intersect at right angies to make a 
convex body. 

[concave region 1 region2] means that regionl and region2 are 
regions of the same brick that intersect at right angles to make a 
concave body. 

[element x y] means that x is an element of y. 

[in-frcnt~of brickl brick2] means that brickl is in front of 
brick2. 

[resting-on brickl brick2] means that brickl is resting on 
brick2. 

[on-top-of brickl brick2] Mans that brickl is on top of 
brick2. 

[subset x y] means that x is a subset of y. 

[coordinates point 1 coordl] means that point 1 has 3- 
dimensional coordinates coordl. 

The following statements about example 1 are valid as can be seen by 
considering mhere the normals of the planes sight lie and deducing 
consequences until contradictions are found. 

[normal a i direct ion 7 13]] 
[normal b [direction 12 13]] 
[convex a b] 



/"■"N 
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EXAMPLE I 




EXAMPLE 2 



/""> 
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[convex a c] 

[convex be] 

[normal c [direction 10 13]] 

[normal d [direction 7 4]] 

[normal e [direction 2 4]] 

[convex d e] 

[normal f [direction 3 4]] 

[convex d f ] 

[convex e f ] 

[normal h [direction 16 18]] 

[noraal g [direction 15 16]] 

[convex g h ] 



The following statement about example 1 satisfiable: 



[and 



[resting-on [brick a 
[resting-on [brick a 



b c] [brick 
b c] [brick 



f d]] 



The following statements about exanple 2 are valid: 



(convex a 
convex a 

[convex b 
[normal a 
[noraal c 
[convex g 
[normal g 
[normal h 
[not [adjacent 
[not [adjacent 



[convex 
[convex 
[convex 
[ normal 
[ normal 
[normal 



si 

c] 

[ direction 

[ direction 

*3 

[ direction 

[direction 

c d]] 

b d]] 



12 1U]J 
3 «]] 



633 

«33 



d e3 

e f 3 

d f3 

e [direction 

4 [direction 

f [direction 



9 
11 



1333 

"33 
1333 



The following statement aboot exanple 2 is satisfiable: 



[and 



[sane-region c g.J 
[sane-region b h} 
[sane-brick a b c 



9 *33 
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The three dinensional coordinates of points are obtained by 
using aore than one caaera to vie* the scene or using a focus sap. In 
the case where we have coordinates as a primitive predicate, the 
definition of a projection of a 3-diaensional scene pust be modified 
to include the 3-dinensional coordinates of all the projected 
vertices. In the case where we have the three dinensional co- 
ordinates of the projected vertices, we can deduce that two planes are 
part of the same brick if the; intersect at an acute right angle. 
Since the. object that is being viewed night be so far away that 
accurate coordinates cannot be obtained, a deductive systea should be 
developed which does not use coordinates. At the very ainiaua a hard 
core deductive systea for the analysis of 2-dinensional projections 
/****% should be consistent and every valid stateaent should be proveabxe* 

That is every theorea cf the systea snould be satisfiable [there is at 
least one interpretation that satisfies the theoreaj. Interest in 
questions of satisfiability cones froa the fact that soae 
interpretations are far aore likely than others in the real world. 
Statements that are to be tested for satisfiability aust be aade as 
strong as possible in order to provide a aeaningful test. Although 
the linking rules are aatheaatically very elegant, xn their present 
fora they do not adequately represent the senantics of the optical 
projection rules. The value of the prcgraa by Guzman is that it 
provides conjectures about which regions are satisfiable ift the 
relation saae- brick ♦ However, the prograa suffers because it does not 
have any explicit knowledge of optics, le would advocate an approach 
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that makes greater use of deduction to test the validity or 
satisfiability of a sentence. Questions of satisfiability and 
validity of sentences with respect to any given projection are 
decidable since the theory of real closed fields is decidable. 
Efficient algoritheas should be developed to test whether a given 
sentence is valid or satisfiable in a projection. 

6.1 .4.4 Power Set of Intersection of Two Sets Is the Intersection of 
Their Power Sets 

The following example was proposed by W. Bledsoe. Prove that 
the power set of the intersection of two sets is the intersection of 
their power sets. He shall use cap as a synonym for intersection. 

<define extensionality-conse <conseguent [[<set> x y]1 

O ?* ?y] 

<goal [subset ?x ?y]> 
<goal [subset ?y ?x]> 
<assert [« .x .y]>» 

<define element-power-conse Consequent [[<set> x all 
[element ?x [power ?a]] * L JJ 

<goal [subset ?x ?a]> 
<assert [element .x [power .a]]>» 

<define element-power-ant Antecedent f[<set> x al] 
[element ?x [power ?aj] 
<assert [subset ?x ?a]>» 

<define subset-cap-ccnse Consequent [[<set> a b ell 
[subset ?c [cap ?a ?b]] 
<goal [subset ?c ?a]> 
<goal [subset ?c ?b]> 
<assert [subset .c [cap .a .b]]>» 

<define subset-cap- ant Antecedent [[<set> a b c]] 
[subset _c [cap _a _b]] 
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< assert [subset .c •a]> 
<assert [subset *c •b]>» 

<define subset-cap-conse <consequent [[<set> a b c]] 
[subset ?c [cap ?a ?b]] 
<goal [subset ?c ?a]> 
<goal [subset ?c ?b]> 
<assert [subset .c [cap .a .b]]>» 

<define element-cap-ant <antecedent [x [<set> a b]] 
[element _x [cap _a _b}] 
<assert [element .x .a]> 
<assert [elesent .x .b]>» 

<define elenent-cap-conse <ccnseguent [x [<set> a b]] 
[elesent ?x [cap ?a ?b]] 

<goal [element ?x ?a]> 

<goal [element ?a ?b]> 

<assert [element ?x [cap ?a ?b]]>» 

<define sabset-conse <conseguent [[<set> a b]] 
[subset _a ?b] 
<temprog~[x <arbitrary <?»] 

<assert [element . i .a]> 
/~\ <goal [element . x .b]» 

<assert [subset .a •b]>» 

le can now set up our goal to prove the theorem: 

<goal [= 

[cap [pover at] [power a2}] 
[power [cap a1 a2]]]> 

The goal will produce the following protocol: 

enter extensionality-conse 

x becomes [cap [power a1] [power a2]] 

y becomses [poirer [cap a1 a2]] 

<goal [subset [cap [power a1] [power a2]][ power [cap a1 a2JJ]> 

enter subset- con se 

a becomes [cap [power a1] [pover a2]] 

b becomes [power [cap a! a2]] 

x becomes g1 

<assert 

[ element 

gi 

[ cap [ power al ] [ power a2 ] ] ]> 
enter elcment-cap-ant 

x becomes g1 
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a beccmes [power a1] 

b becomes [ power a2 ] 

<assert [element g1 [power a1]]> 

enter element-power-ant 

<assert [subset g1 a1]> 
<assert [element g1 [power a2]]> 
enter element-power-ant 

<assert [subset g1 a2 ]> 
<goal [element gl [power [cap a1 a2]]]> 
enter element-power-conse 
x becomes g1 
a becomes [cap a1 a2] 
<goal [subset g1 [cap a1 a2]]> 
enter subset-cap-conse 

c becomes g1 

a becomes a1 

b becomes a2 

<goal [subset g1 a1]> 

<goal [subset g1 a2 ]> 

<assert 

[ subset 



<assert 

[subset 



<goal 

[subset 



<assert 

[element 

gi 

[power [cap ai a2]]]> 



gi 

[cap a1 a2] ]> 



[cap [power a1] [power a2]] 
[power [cap a1 a2]]]> 



[power [cap a1 a2]] 

[cap [power a1 ] [power a2]]]> 



enter subset-conse 

a becomes [power [cap a1 a2j] 
b becomes [cap [power a1] [power a2]] 
x becomes g2 

<assert [element g2 [power [cap a1 a2]]]> 
enter eleuent-power-aat 
x becomes g2 
a becomes [cap a1 a2] 
<assert [subset g2 [cap at a2]]> 
enter subset-cap-ant 
x becomes g2 
a becomes a1 
b becomes a2 
<a sse rt [ subset g2 ai ]> 
<assert [subset q2 a2]> 
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<goal 

[eleaent 

g2 

[cap [power a1] [power a2]]]> 
enter eleaent-cap-conse 
x becomes g2 
a becoaes [power a1] 
b becoaes [power a2 ] 
<gcal [eleaent g2 [power a1]]> 
eater eleaent-pover-conse 

x beccaes g2 

a becoaes a1 

<goal [subset g2 a1]> 
<goal [eleaent g2 [power a2]]> 
enter eleaeat-power-conse 

x becoaes g2 

a becoaes a1 

<goal [subset g2a1]> 
<assert 

[ eleaent 

g2 

[cap [power a1] [power a2]]]> 
<assert 

[ subset 
^ [power [cap a1 a2]] 

# [cap [power a1] [power a2]]]> 



<assert 



/■> 



[power [cap a1 a2]] 

[cap [power a1] [power a2]]]> 



6.1.5 Seaantics of Natural Language 

Although probleas for PLAHHEH are typically phrased in a 
perfectly fernal, precise, unaabiguous syntax, we will usually not 
find the seaantics as well defined. If we say [[*ery happy] John } 
instead of "John is very happy. « we nill not thereby have aade the 
concept of happiness any less nebulous for the aachine. nevertheless 
it is convenient for a problea solver to have such concepts although 
they are not rigorously defined. Probleas of seaantic aabiguity and 



6. 1 page 277 

clarificatcn can require arbitrary amounts of computation in order to 
be adequately resolved. For example consider the following simple 
example of how semantic ambiguities can be eliminated with the aid of 
,f real- world" Knowledge: 

<assert [ is-smaller-than hand [pig pen]]> 

<assert 

<define example-of-bar-hillel 

<antecedent [[<object> x y]] 
[in _x _y] 
<cond 

[ <is? pen . x> 

<goal [ is-sraaller-than ?y [pig pen ] ]> 
<assert [in [fountain pen] . y ]>]»>> 

Now if wc assert £ic pen hand], PLANNER will conclude that [in 
[fountain pen] hand] is true since a hand is smaller than a pig pen. 
One cf the important difficulties that have plagued most of the 
programs that have been written to answer questions in English is that 
they are trying to solve two very hard problems at the same time. 
First they must maJce sense of English syntax and second they need a 
powerful problem solving capability to answer the question once they 
have "understood" it. Ambiguous cases shculd be resolved on the basis 
of deduction and not on the basis of seme linking scheme such as 
"semantic memory". As it stands PLANNER provides sophisticated 
mechanisms for solving problems in formal languages. A program could 
be written [perhaps in PLANNER?] to translate English into PLANNER 
theorems for problem solving. Conversely we could try to translate 
PLANNER theorems into simple natural language. Surprisingly 
translation into natural language can be very awkward because natural 
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THE PONS ASINCRUM 
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GIVEN : AB = AC 
PROVE :^ABC = <*ACB 



r^ 



DIAGRAMS FOR GEOMETRY THEOREMS 



SIDE-ANGLE-SIDE 





[CONGRUENT [x,x 2 x 3 ] [y 3 y 2 y 1 ]] 



EQUAL-ANGLE 




[EQUAL [ANGLE p t p g p 3 l [ANGLE P3P2P,]] 
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language lacks many of the descriptive and procedural primitives of 
PLAKNE8. 



6.1.6 The Pons Asinorum 

He would like to show how the "bewildering ly simple" proof of 
the pons asinorum [i. e., base angles of aa isoscles triangle are 
equal] can be done very simply in PLANNEH. The following notation 
will be used: 

[length Jp1J |f2l] for the length from point |p1| to Jp2| 

[angle lx] 1 y | lzl] for the angle Jxj i y | Iz| which has the 
point |yl at xts vertex 

/""^ Pour PLANNER theorems are used. They are procedural analogues of 
axioms in plane Euclidean geometry. 

<define side-angle-side 

<conseguent [x1 x2 x3 y 1 y2 y3 ] 

[congruent [?x1 ?x2 ?x3 ] [?y1 ?y2 ?y3]] 
<unigue> 

<goal [- [length ?x1 7x2 ] [length ?y1 ?y2]}> 
<goal [= [angle ?x1 ?x2 ?x3] [angle ?y1 ?y2 ?y3]]> 
<goal [» [length ?x2 ?x3] [lengtb ly2 ?y3]]>» 

<define equal-anqle 

<coaseguent [p1 p2 p3 w] 

[= [angle ?p1 ?p2 ?p3] ?w] 
<unique> 
<goal [= [angle ?p3 ?p2 ?p1 ] ?w]>» 

<define equal 

<consequent [x y] 
[- ?x ?y] 

<unique> 
<or 

<match ?x ?y> 
^ <goal [* ?y ?x]»» 
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<define angles-by-congruence 

<conseguent [pi p2 p3 g1 g2 g3] 

[« [angle ?p1 ?p2 ?p3] [angle ?gl ?g2 ?g3}] 
<unique> 
<goal 

[congruent 

[?p1 ?p2 ?p3] 
[?g1 ?g2 ?q3]]>» 

Suppose that ae have ai> isosceles triangle ABC with the length of AB 
equal to the length of AC. lie can input this as: 

<a sse rt [» [length A B] [length A C]]> 
The goal is to prove that angle ABC is equal to angle ACB: 

<goal [* [angle ABC] [angle A C B]]> 

One protocol for establishing the goal is: 
enter angle-by-congruence 

p1 becoaes A 
p2 becoaes B 
p3 be cones C 
q1 becoaes A 
q2 becoaes C 
q3 becones B 

<goal [congruent [ABC][ACB]]> 
enter side-angle-side 
p1 becoaes A 
p2 becoaes B 
p3 becoaes C 
q1 becoaes A 
q2 becoaes C 
q3 becoaes B 

<goal [* [length A B] [length A CJ]> is easy since it is In 
the data base 

<go*l [« [aagle B A C] [angle C A B]]> 
enter equal-angle 
p1 becoaes B 
p2 becoaes A 
p3 becoaes C 
v becoaes [angle CAB] 
<goal [- [angle CAB] [angle C A B]]> 
enter equal 

x becoaes [aagle CAB] 
y becoaes [angle CAB] 



6. 1 page 280 

<goal [- [length A C] [length A B]]> 
enter egual 

x becomes [length AC] 
y becomes [length A B] 

<goal [* [length A B] [length A C]]> succeeds by 
looking in the data base 



Ira Goldstein has iMplemented a Gerlernter-liXe geometry 

theorem prover. 



/**> 
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6.2 Current Problems and Future Hork 



PIANNEE would benefit greatly from an efficient parallel 
processing capability. The system would run faster if it could work 
on its goals in parallel. Quite often a goal will fail arxer a short 
computation along its path. The use of parallelism would enable us to 
get many goals to fail so that we could adopt more of a progressive 
refinement strategy. Me would like to carry out computations to try 
to reject a proposed subgoal at the same time that we are trying to 
satisfy it. Hany computations can be carried out much faster in 
parallel than in serial. For example we can determine whether a graph 
with n nodes is connected or not in a time proportional to <* <log n> 
<log n». It has been kaown for a long time that LISP computations 
using parallel evaluation of arguments are determinate if the 
functions rplaca # rplacd, and setg are prohibited. »e could impose a 
similar set of restrictions on PLAHNEB. Another approach is to 
introduce explicit parallelism into the control structure. He have 
n \<" and »>« delimit parallel calls for elements and *| {« and «}* 
delimit parallel calls for segements. A parallel function call will 
act as a fork in which one process is created to do the function call 
^nd the other proceeds with normal order evaluation, For example in 
<♦ l<* 3 4> <* 7 8» we could compute 3*4 in parallel with 7+8. The 
copy function could be sped up by a factor proportional to the nunber 
of processors: 
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<define copy [function [x] 
<cond 

[<is? <ncnadic> .x> 
.x] 
[-•••else 11 

[l<copy <1 .x» (copy <rest .x>}]]>]> 

However, we would still have problems communicating between the 
branches of the computation proceeding in parallel. Partly this a 
problem of sharing an indexed global data base between parallel 
processes. He would need the standard lock and unlock primitives and 
unlimited use of assignment in order to keep the computations 
synchronized. But if we allowed the use of lock and unlock and 
unlimited use of assignment the programs might become indeterminate • 
^*N One of the most important properties that can be proved about a 
program is that it is determinate. 

PLANNEB logic is a kind of hybrid between the classical logics 
[such as the guantif icational calculus and intuit ionistic logic], and 
the recursive functions [as represented by the lambda calculus and 
Post productions]. The semantics of PLAHBER logic is most naturally 
defined dynamically by the properties of procedures. The semantics of 
the guantif icational calculus can be defined by set theoretic models 
of possible worlds. The logic of the guantif icational calculus is 
CONSERVATIVE in the sense that if a sentence S follows from a set of 
sentences H then S will follow from any superset of H. Do to its 
ability to have conditional expressions that test the state of the 
world, PLANNER logic is HOT conservative. This causes consternation 
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among classical logicians because many elegant theorems for classical 
logic do not hold for PLANNEB logic* The restriction of having to be 
conservative is quite severe in problem solving. Suppose that there 
are three cubes A, B # and C sitting on a table. Suppose that it is 
desired to build a tower two cubes high at place E. The plan 
constructed might be to pick up A, set it down at P # and then place B 
on top of it. If in the process of constructing the plan we deduced 
that cube A was glued to the table with liguid iron, we would want to 
change our plan to use cubes B and C to make the tower. But by the 
conservative properties of ordinary logic the original plan must 
remain valid. The only way around this would appear to be introduce 
some special kind of internal state into the deductire machinery of 
the quantif icational calculus. Recommendations are another source of 
nonconservative behavior in PLANNEB. For example we might not allow 
Zorn's Lemma to be used more than once in a proof. Both PLANNEB logic 
and guantif icational logic are COMPACT in the sense that a computation 
[proof ] depends on only a finite number of expressions. In comparison 
with the quantif icational calculus PLANUM would appear to be more 
powerful in the following areas: 

control structure 

pattern matching 

erasure 

local states of world 

There are interesting parallels between theorem proving and 
algebraic manipulation. The two fields face similar problems on the 
issues of simplification, equivalence of expressions, intermediate 
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expression bulge # and Ban- machine interaction* The parallel extends 
to tne trade off between domain dependent knowledge and efficiency. 
In any particular case, the theorems need not allow PLAHHER to lapse 
into its default conditions. It will sometimes happen that the 
heuristics for a problem are very good and that the proof proceeds 
smoothly until almost the very end. Then the progam gets stuck and 
lapses into default conditions to try to push through the proof. On 
the other hand the program might grope for a while trying to get 
started and then latch onto a theorem that knows how to polish off the 
problem in a lengthy but fool proof computation. PLASHES is designed 
for use where one has great number of interrelated procedures 
[theorems] that might be of use in solving some problem along with a 
/ —-, general plan for the solution of the problem. The language helps to 
select procedures to refine the plan and to sequence through these 
procedures in a flexible way in case everything does not go exactly 
according to the plan. The fact that PIABHEB is phrased in the form 
of a language forces us to think more systematically about the 
primitives needed for problem solving. He do not believe that 
computers will be able to prove deep mathematical theorems without the 
use of a powerful control structure. Hor do we believe that computers 
can solve difficult problems where their domain dependent knowledge is 
limited to finite-state difference tables of connections between goals 
and methods. Difference tables can be trivially simulated by 
conditional expressions in PLAIHEB. 
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Difficult problems for PIAHBEB 



Be would be grateful tc any reader who could suggest types of problems 
which light be difficult to encompass naturally within the present 
formalism. P1ANHEB is intended to be a good language for the 
creation and description of problem solving strategies. Currently it 
operates within the restriction of generalized stack discipline. By 
relaxing this restriction we could make the language completely 
restartable at the considerable cost in efficiency of having to 
garbage collect the stack. 

Speed: PLANNEB runs best on a fast general purpose computer. 
However two special kinds of hardware would be useful* Alan Kay has 
pointed out that special hash code hardware could make the functions 
GET and POT as fast for nodes as indexing hardware does for vectors. 
Second if we had a load thru mask instruction, then we could speed up 
monitoring. The instruction would interrupt if the appropriate 
monitor bits were on. Both of the above kinds of instructions should 
probably be micro-coded. 

Hemorys There is never enough fast random access storage. 
Furthermore the eighteen bit address space of the PDP-10 is 
inadequate. le need a bigger address space for the following 
purposes: 
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stacks ] 
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Garbage collection 

Breathing space between data spaces [especially 



Backtracking 
Dynamic linking 

Exploding definitions: We cannot afford to replace every term 
by its definition in trying tc prove theorems* However , in the proof 
of almost every theorem it is necessary to replace some terms by their 
definitions. Domain dependent methods must be developed to make the 
decision in each case* 

Creating PLAHNEB theorems: We need to determine when it is 
desireable to construct PLAHHEB theorems as opposed to dynamically 
linking them together at run time. At the present we have only a few 
examples of nontrivial constructed theorems. He can generate some 
from the functional abstraction of protocols and from attempts to 
construct schematic proofs of theorems* others are generated as the 
answers to simple problems. For example if we ask the computer hov it 
would put all the small green and yellow bricks in the red box, then 
it might ansver: 



<for [£<face> facel f ace2 ] £<brick> brick]! 

[[-."current* [small-brick J jbrickj] J 

<current [face _face1 .brick ]> ~ 

<curxent £ color .facel green ]> 

<cur rent [face _face2 .brick ]> 

<current [color~.£ac«2 yellow ]> 

<pick-up .brick> 

<carry-to [above [re$ box]]> 

<drop» 
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Terry Minograd has developed a program to translate English into 
PLAMHEB theorems. An interesting expreriment that could be attempted 
would be to aodify a chess porgraa so that it would return a PLANNER 
program as well as the symbolic description of a position. The idea 
is that the PLANHEB program would represent the plan of action that 
would be taken in case of the various moves that the opponent Bight 
take. Billiaa Henneman has investigated some of the possibilites for 
doing planning in king and pawn end gases. The problea seems to be 
very difficult but not impossible given the present state of the art- 
Arbitrary Constraints: Using procedures as a semantic base 
reguires us to solve the problem of making procedural formalisms more 
goal-oriented. The guantif icational calculus is very goal oriented 
but suffers growing pains trying to introduce procedural knowledge. 

Hanipulation of PLANHEB theorems: PLAHHEB provides a flexible 
computational base for manipulating theorems that can be put in 
disjunctive normal form. Ve need to deepen our understanding so that 
we can carry out siwilar manipulations on PLAHHEB theorems with the 
same facility. 

Progressive refinement: tie need to make mare use of the style 
of reasoning in which we construct a plan tor the solution of a 
problem from necessary conditions that the solution must have, attempt 
to execute the plan, find out whv it does not work, and then try 
again. The style is often used in chess where very much the oaie 
game tree is gone over several times; each time with a deeper 
understanding of what factors are relevant to the solution. 
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Garbage collection of assertions: Statements which have been 
asserted should go away automatically when they can no longer be of 
use. unfortunately , because cf some logical problems and becuause of 
the retrieval system of PLANHER, we have difficulty in achieving 
completely autcaatic garbage collection. The erase primitive of the 
language provides one way to get rid of unwanted statements. If the 
asserted statement appears in the local state of some process instead 
of in the global data base then it will disappear automatically* 

Simultaneous goals: Be often find that we need to satisfy 
several goals simultaneously. We usually try to accomplish this by 
choosing one of the goals to try to achieve first. However , whea 
working on the goal* we should keep in mind the other constraints that 
/""*% the goal must satisfy. One solution is to pass the goal to be worked 
on as a list whose first element is the goal and whose succeeding 
elements are the other goals which must be simultaneously satisfied. 

Homconstructive proofs: The most natural way to do a proof by 
contradiction is to try to calculate in advance the statement which 
ultimately will produce the contradiction. The method is to find a 
statement S such that S is provable and [not S] is provable. Bore 
precisely, we compute a statement S, make S a goal, and then make [not 
S] a goal. Bob Boyer has pointed out that in mathematics if the goal 
is tc prove S, then if at any point in the proof the main goal reduces 
to the subgoal to prove [not S], then a proof by contradiction cam be 
completed. 

Ho dels of Domains: Suppose that B is model for the set of 
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hypotheses H with ccnseguent C. Using constructive logic a subgoal S 
of the goal C would be rejected if it could be shown that it was 
unsatisf iable by H. Often rejections are made on the basis of a model. 
For example in the intuitive model of Zermelo-Fraenkel set theory all 
the descending element chains are finite and terminate in the null 
set. Furthermore every set has an ordinal rank. Thus the ordinals 
form the tack bone of the set theory. The intuitive meaning of [♦ A 
B] [where A and B are ordinals] is the concatenation of A with B. The 
intuitive meaning of [* A B] is the concatenation of A with itself B 
times. If two ordinals have the same order type then they are equal. 
Thus intuitively we would expect that [- [♦ 1 omega] omega] is true. 
Every well developed mathematical domain is built around a complex of 
intuitive models and simple examples and procedures. Axiom sets are 
constructed to attempt to rigorously capture and delineate various 
parts of the cctplex. One of the most important criteria for judging 
the importance of a theorem is the extent to which it sheds light on 
the complex of the dcmain. These complexes must be mechanized. Ve 
conclude that it is unlikely that deep mathematical theorems can be 
proved solely from axioms and definitions by a uniform proof 
procedure. A uniform proof procedure based on model resolution does 
not provide the means for mechanizing the complex of a dcmain. Hodel 
resolution is a strategy for deciding which clauses to resolve. There 
is a great deal more tc mechanizing the complex of a domain than 
simply pruning proof trees. Furthermore, clauses are often false in a 
model even though they are irrelevant to the proof that is being 
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sought* One nay that is often used to try to find a counterexample 
to a false statement about ordinals is to attempt to construct the 
counterexample froa veil Xnovn ordinals. Soae veil known ordinals are 
1, 2, 3, onega, the least uncountable ordinal, etc. Thus in seeking a 
counter example to the statement that there are only finitely many 
limit ordinals less than a given ordinal we need go no further than [* 
oaega omega]. 
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7. Models of Procedures and the Teaching of Procedures 



7.1 So dels of Procedures 



7.1.1 Bodels of Expressions: Intentions in IHTEHDEE 

A problem solver needs to have some way to knew the properties 
of the procedures which it uses to solve problems, it can use tho 
knowledge which it has as a partial node! of itself. In order to be 
able to model procedures, it needs: 

1: a way to express properties of procedures. 

2: i way to establish that the properties do in fact hold for 
the procedures. 

IHTEHDEE is a goal-oriented formalism for expression? models 
of procedures. The models are expressed in terns of intentions of 
what the procedure should accomplish. The primitives of IHTEHDEE are 
concerned with expressing intentions in procedural terns. Thns the 
intentions are capable of thenselves having intentions. IHTEHDSP 
mechanizes the knowledge needed to do execution induction on 
procedures. It calls on P1AHHEB to satisfy goals and uses PLAHIEB 
theorems to hold the substantive knowledge (suck as facts about 
integers) which are needed to prove properties of procedures. 
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INTENDER has three sain uses for PLANNEB: 

1: It enables PLANNER to verify that its procedures 
do what is intended. 

2: Host knowledge in PLANNER is embedded in 
procedures. INTENDER helps PLANNER understand these 

procedures and thus to have some knowledge of its own 

problem solving behaviour. 

3: INIENDKR enables PIANNER to verify that its plans 
(procedures) are valid relative to its procedural 

model of the world. 

We shall express the properties of an expression x by the 
following function. 

<INTENT 

[-declaraticns- ] J predecessor J JxJ Jf unction | - 
successors-> is true if Jpredecessorj evaluates to true # the function 
applied to the value of JxJ is true, and the -successors- all evaluate 
to true. The value of the function intent is the value of Jx|. The 
function intent is used to state a model for an expression x. As might 
be expected the models are stated in PLANNER. The intentions are 
established by INTENDER which is the language in which intentions are 
stated. The proof is by induction on the activations of the 
procedure. Thus for the control structure of LISP # the proof is by 
recursion induction. To avoid confusion we shall write the intention 
variables in upper case. Also we shall use ! • to suppress 
invocations. Thus <♦ 2 3> evaluates to the number 5 while !*<♦ 2 3> 
evaluates to <♦ 2 3>. For example the intentions in the prog below 
are all true. 
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<prog foo [fa t] fb 2]J 

!;<intent [] <goal !•<£= 1 ,a>» 
; M Yes the identifier ae was 

indeed initialized 5 to 1. Will »o»ders never cease?* 
!;<intent [] <goal !•<= .b !•<♦ .a 1>»» 
! ;<intent [ ] 

<goal !'<= .b 2» 

<_ zb <* .b 1» 

<f unction [X] <goall !•<= .X 3>» 

<goal !»<=.b 3>» 
;**9e have just verified that an assignment statement 

can change the value of the identifier b from 2 to 3" 
<.foo .b> 
;«*exit .foo with .b"> 

The following protocol for 1HTENDEB verifies that the 
intentions in the above program do in fact hold, le shall use the 
notation J identifier J_ jn J for the In !th value of (identifier! and 
Jidenifierl_ for the initial value. 

<assert !•<= 1 a » 
<assert !•<« 2 b~» 
<goal !•<= 1 a >> 
<goal !•<= b T»<+ a 1»> 
<goal !••<* 2 b » 
<assert !•<= b~1 <♦ b 1>» 
<goal !«<*<♦ b 1> 3>> 
<goal !«<= b_1 3» 

The essential idea for intentions comes frcm the break 
function introduced into Lisp by H. Martin. An intention is not 
allowed to assign a value to a non-intention identifier amd ordinary 
code is not allowed to reference intention identifiers. Me shall 
distinguish intention identifiers from ordinary identifiers by putting 
them in all caps. The intention 

<IHTEHD 

[-declarations-] J predecessor! (expression) 
|function|> is exactly like the function intent except that intention 
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variables can be declared in the declaration* In addition ve need a 
function 

<0VEHA11 

[- declarat icns- ] J predecessor 1 J expression J 
|function|> which is exactly like the function IBTEHD except that it 
is used to state the overall intention of a procedure. If 
1 expression! is a junction then the overall input output intentions of 
the junction are given by (predecessor] and J function J. Thus IHTENDER 
does computational induction across process boundaries* All the 
intentions in the function fact are true where 

<define fact <function fact [n] 
<overall [ ] 

<intention [ ] 
^"■^ <goal ! f <is? ! , <non-neg> .n>> 

<assert !'<is? !»<non-neg> •n>» 
<repeat ££teap 1] £i 0]] 
! ;<intention [ ] 
<prog [ ] 

<goal ! f <is? ! , <non-neg> .i» 
<goal !•<» .temp ! ^factorial •!»» 
<prog [ ] 

<assert ! f <is? ! f <non-neg> • i» 
<assert !•<= *teap <factorial *i>»» 
<coad 

[<is? *n .i> 

<*fact •temp> 
;»exit .fact with •tetF i, ]> 
<_ :i <♦ .i 1» 
<_ ;tenp <* .i .te«p>» 
<fnnction £X] 
<intention [ ] 

<asscrt !•<« .X !*<factorial *n>» 
<goal !•<- .X ! f <factorial •n»»»» 

where 
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<define factorial <f unction [n] 
<overall [ ] J 

<intention £ ] 



7. 1 page 295 

<goal ! f <is? ! f <non-neg> *n>> 
<assert ! Kis? ! , <non-neg> «n>» 
<cond 

[<is? C .n> 

1] 
[-•"else" 

<* .n <factorial <- .n 1>»]> 

<f unction [X] 

<intention [ J 

<ptog [ ] 

<cond 

[S<goal !•<= .n 0» 

<assert !»<= .X 1»] 

£<goal !'<not !•<= .n 0»> 

<assert 

.X 

!*<* .n !»<fact !'<- .n 1>»» ]> 
<assert !•<= .X ! ^combinations .n 0>» 
<assert !•<= .X !«<fact .n»» 
<prog [ ] 
<qond 

[€<goal !»<= .n 0» 

<goal !•<= .X 1»] 
[6<goal !'<not !»<= .n 0>» 

<goal !•<= .X !•<* .n !»<fact !«<- .n 1>»»]> 
<goal !»<= .X !* Combinations . n 0>>> 
<goal !»<= .X !*<fact .n»»»»> 

The following is a protocol of the action of INTENDE8 on the 
intentions of fact: 

<assert ! '<is? !»<non-neg> n_» 
enter intentions of repeat 

Case 1: initial entry 
<assert !•<= 1 temp_» 

<assert !«<= i_»~ 

<goal ! Kis?""! »<ijon~neg> i » 
<goal !•<= 1 !»<factorial 0>» 

enter intentions of factorial 
n becomes 
X becomes 1 

<goal !'<is? !«<non-neg> 1» 
<goal !*<= 1 1» 
<assert !»<= 1 !»<factorial 0>» 
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Case 2: inductively assune 
<assert M<is? ! f <non-neg> i_>> 
<assert !•<= temp_ ! f <£actorIal i_»> 
enter conditional 

Case 1: 

<assert !'<- n_ i_» 

<goal !*<-~teBp_ ! ^factorial n_>» 

Case 2: 

<assert !«<not ! f <~ n_ i_>» 

<assert !•<= i_1 !'<♦ i_ 1»> 
<assert ! f <= 

temp 1 

!*<*~i_1 temF_>» 
<goal P<* temp_1 !«<factorial i_1>» 
enter intentions of factorial 
n becomes i_1 
X becomes teap_1 
<goal ! f <is? M<non-neg> i 1» 
<gcal !•<= i_1» 
FAIL 
<gcal ! f <= 

i 1 

!• factorial !"»<- i 1 1>» 
teip 1» 
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On the other hand if INTENDED analyzes the intentions of 
factorial tie get: 

<assert !»<is? ! f <non-neg> n_>> 
enter conditional 

Case 1 * 

<assert !•<* n » 

<goal !*<= 1 !»<fact C>» 
enter intentions of fact 
n bcccies 
X becomes 1 
<goal !•<= 0» 
<goal !•<= 1 1» 

Case2* 

<assert !«<not !•<* n_>» 
<assert ! ■ <= "" 

!«<£actorial !•<- n 1» 
^ !«<fact !•<- n 1»>> 



7. 1 page 297 

<goal !•<= 

n_ 

! "^factorial ! •<- n 1» 
!»<fact n_»» 
enter intentions of fact 
n beccaes n_ 
X becomes "" 

n_ 

! 7 <factorial !•<- n 1>» 
<goal !»<= 

ii 

l 7 <factorial !»<- n_ 1>» 
!* Combinations n 0»> 
<goal !»<* 

n_ 

J T <factorial '»<- a 1»> 

n_ 

!»"<fact !•<- «_ 1>»» 

The intentions for the function fctrl defined below are not so 
easy to establish. 



<define fctrl <f unction fctrl [n] 
<overall ££ABG .n]] 
<intention [ ] 

<goal !*<is? !»<non-neg> .n» 
<assert ! «<is? ! , <ocn-neg> .n»> 
<repeat [[temp 1]] 
! ; <intention [ ] 

<goal !•<* .temp ! ^combinations .ABG ,n>» 
< assert !•<* .temp ! ^combinations .ABG .u»» 
<cond 

£<is? .o> 

<. fctrl . temp> 
;"exit .fctrl mith ,temp«]> 
<_ :temp <* .temp .a» 
< :n <- .n 1>» 
<f unction £X] 
<intentioa £ J 

< assert !•<« .1 !• factorial .ABG»> 
<goal !•<= .X ! ^factorial .ABG»»»» 
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He need to define an auxiliary function in order to do the proof: 

<define coibinations <f unction [n r] 
<overall [ ] 



<intention 

<and 



<and 



6<goal !*<is? !'<non-neg> .n» 
&<goal ! f <is? ! f <non-neg> .r» 
6<goal ! f <is? ! f <greater= .r> *n»> 



S<assert ! f <is? ! f <non-neg> .n» 
5< assert i f <is? l f <non-neg> .r» 
&<assert !*<is? ! f <greater- .r> • n»» 

<cond 

[<is? .n .x> 

1] 
[^«ei.se w 

<* .n <ccBbinations <- .n 1> .£>>]> 
<f unction [I] 

<intention [ ] 
<prog [] 

<cond 

[6<goal !•<= .n .r» 
/-n <assert !•<= 1 ,X»] 

[8<goal !•<* .r 0» 

<assert !•<=.* !«<factorial •n>»]> 
<a ss ert 

J f <coabinations !•<- *n 1> .r> 

• B»» 

<prog [] 

<cond 

[6<goal !•<* .n .r» 

<goal !•<* 1 •!»] 
[<goal !•<* *r 0» 
<goal !•<* .X !«<factorial .n>»]> 
<goal 

! f <coabinations !«<- # n 1> *r> 
♦n>»»»» 

IBTEHDEB yields the following protocol for the intentions of 
fctrl: 
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<assert ! f <is? !'<ncn-neg> n >> 
enter intentions of repeat ~ 

Case 1: initial entry 

<assert ! f <= 1 temp_>> 

<goal !•<= 1 ! • Combinations n_ n_>» 

enter intentions of combinations 

n becomes n_ 

r becomes n_ 

<goal ! f <is? ! f <non-neg> n_>> 

<goal ! f <is? ! f <non~neg> n_» 

<goal ! f <is? !*<greater= n~> n_» 

<goal ! f <= n_ n » 

<goai !•<= 1 1>> 

rase 2: inductively assume 
<assert 

temp_ 

!• Combinations n_ n_>» 
enter conditional 

Casein 

<assert ! f <- n_1» 

<goal !•<- temp_ ! f <f actor iai n_>>> 

enter intentions of factorial 

n becomes n_ 
X becomes temp_ 
<gcal 

temp_ 

! 'Combinations n 0»> 



Case2: 














<assert !'<not !' 


•<= 


n_ 


1>» 






<assert 


!•<= 




tenp 


.1 












!•<*" 


teap 


n 


1>» 


<assert 


!»<= 


n_ 


2 !•<- 


■ o~ 


"l>~ 


*» 


<goal !' 


><» 













temp_1 

!* Combinations n_ n_2»> 
enter intentions of combinations 
n becomes n_ 
r becomes n_2 
X becomes temp_1 
<goal ! f <is? ! f <non-neg> n_» 
<goal ! f <is? ! f <non-neg> n_2» 
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<goal ! f <is? ! f <greater- n_2> n_» 
<gcal !'<^ 

temp 1 

! ^combinations 

n 

n~1> 
n_1>» 

He can use the same techniques for showing that a procedure 
will converge if its arguments satisfy certain conditions* The idea 
is tc define a partial order with no infinite descending chains and 
then prove that every time control goes through the same point in the 
program that it has descended in the partial order. The ordering we 
shall use is that [ SHA1LEB [Jal ibj |c|] [ |dj JeJ jf|]] is true if one 
of the following three conditions holds: 

la | is less than Jd| 

Jal=IeJ and ]b| is less than ]e| 

|as]-le( and |b]-]e| and |c| is less than \t\ For example 
consider Ackeman* s function as defined below: 

<define ackerman < function [2 x y] 
<overall [ ] 

<intention [ ] 
<prog [ ] 

<goal !'<is? ! , <non-neg> .z>> 
<goal ! f <is? ! , <non-neg> .x>> 
<goal ! f <is? ! f <non-neg> .y>» 
<prog [ ] 

<assert ! f <is? ! f <non-neg> . 2» 
<assert IKis? ! f <non-neg> . x>> 
<assert ! f <is? ! , <non-neg> .y>» 
smaller> 
<cond 

[<is? .x> 

<rule [ ] .z 

[0 .y] 

[1 03 

[<greater 1> 1 3> 3 
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[<is? .2> 

<♦ 

<ackerman <- . x 1> . y> 

1>] 
[-•"else" 

<ackerman 

<• .z 1> 

Cackerman .z <- .x 1> •y> 

•y>]> 

<f unction [w] 

<intention [ J 

<assert ! f <is? ! l <non-neg> . w>> 
<goal ! f <is? ! f <non-neg> .*»»>» 



<aefine show-snaller <conseguent [abcdef] 
[smaller [ ?a ?b ?c] [ ?d ?e ?£]] 
<cond 

[S<goal ! f <is? !'<less ?d> ?a»] 
££<goal !•<=* ?a ?d» 
<cond 

[6<goal ! f <is? ! »<less ?e> ?b»J 
[6<goal !•<« ?b ?e» 

<goal !«<is? ! c <less ?f> ?c»] 
[-"else" <fail>]>] 
[-•"else" <fail>]>» 

The protocol for PLAHMEB on ackerman's function is: 

<assert ! f <is? ! f <non-neg> z » 

<assert ! f <is? ! f <non-neg> x~» 

<assert ! f <is? ! f <non-neg> y^» 
enter conditional ~* 

Case 1: 

<assert ! « x_» 

<assert ! f <is? ! f <greater 0> x_» 

Case 2: 

<assert !•<= z_» 
<goal [s sailer 

£0 !•<- x 1> y ] 
[0 x_ y_j]> 
enter show-saaller 
a becoaes 
b becomes !•■<- x_ 1> 
c becomes y_ ~ 
d becomes 0~ 
e becomes x 
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f iecoaes y_ 

<goal !~<is ! f <less 0> 0» 

FAIL 

<goai !•<= 0» 

<gcal !«<less x_> !•<- x_ 1» 

<assert !*<is? !*<greater 0> z>> 

Case 3; 

<goal [saaller 

[z !•<- x 1> y ] 

irT *- Y_3> 
<goal [saaller 

£!•<- z 1> <acfceraan z ! •<- x 1> y > y >] 

[z_ *_ 7-33> 

We would like to show that if we reverse a list tvice then ve 
get the original list. 



<define reverse <f auction rev [1] 
<overall [ 3 
t 
<repeat [[u .1] £v {) ]] 
!;<intention [] 

<goal !»<is? .v !*<reverse !'<s«b .3 ♦ «»» 
<assert !*<is? .v !•< reverse !*<sab .1 .a>»» 

<COQd 

[<eapty? ,o> 
<.rev -v> 

;"exit .rev with . v ,, 3> 
<„ ;* (<*• •«> l.v) > 
<_ :o <rest .u»> 
<f unction [X] 

^intention £ ] 
<aad 

<cond 

[<is? () .1> 

<assert ! •<* .X ()»3> 
<assert !«<is? .X !«<rev .!»> 
<assert 1 »<is? .1 ! ( <reverse .X»» 
<prog i ] 

<cond 

[<is? .!> 

5<goal :»<= .X ()»3> 
6<goal !«<is? .X !»<rev .1>» 
$<goal !»<is? .1 !*<reverse .X>»»»» 
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He would like to show that for all \l\ that <reverse <reverse Il|» is 
| X J * Again we will neea a helping function to express our intentions* 
We stall define <S0B ] xj |y|> to be |x| subtract JyJ as lists. 

<define last <f unction [x] 

<cond 

[<empty? <rest .x>> 

<1 .x>] 
[-•"else" 

<last <rest •x»]>» 

<define butlast <f unction [x] 
<cond 

[<eiipty? <rest • x» 

OJ 

[-"•'•else* 

(<1 .x> <butlast <rest . x»]>» 

<define sub <f unction £x y] 
<overall [ ] 

t 

<cond 

[<is? .x . y> 

3 
T ~* w else f * 

(<1 ,x> fsub <rest . »>} .y) ]> 
<f unction [Z] 

<intenticn [ ] 
<cond 

[S<goal !'<is? .y <)» 

<assert !»<is? .2 .x>>J 
[&<goal !«<not ! »<is? .y >» 
<assert !•<= 

!»<last !»<sub .x !«<rest .y>» 
!«<1 .y>» 
< assert ! « <= 
.Z 

!»<butlast !»<sub .x !»<rest .y>»»]> 
<cond 

£6<goal !«<is? .y () » 

<goal !*<is? ,Z .x»] 
[S<goal !»<not ! »<is? .y () >» 
<goal !•<= 

!»<last !»<sub .x !»<rest ,y»> 
!»<1 ,y»> 
<goal !'<= 
.Z 

!»<butlast !«<sub .x !«<rest 
.y»»>]»»» 
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<define rev <f unction [list] 
<overall [ ] 
t 
<cond 

[<monad? . list> 

• list ] 
t> f, else n 

(<last . list> {rev <butlast •list>}) ]> 
<f unction [X] 

<intention [ ] 
<prog [ ] 

<assert !*<is? ,X ! f <reverse •list>» 
<assert !*<is? .list !*<re verse .X»» 
<prog [ ] 

<goal ! f <is? .X ! f <reverse •list»> 
<goal !*<is? .list !«<reverse •X>»»»» 

The protocol of I8TBNDEE on BEVEBSE is: 
enter intentions of repeat 



/~\ 



Case 1 : initial entry 
<assert ! f <=* u_ 1_» 
<assert ! f <- v () » 

<goal !«<is? () ! f <reverse ! *<sub 1_ 1_»» 
enter intentions of sub 
x becoaes {) 
y b€ccBes {) 

<assert ! f <= {) ! f ^sub 1_ 1_>» 
enter intentions of reverse 
1 bccoses () 
<assert !•<- {) IKreverse () >» 



Case 2: inductive hypothesis 

<assert ! # <is v_ !*<reverse ! f <sub 1_ u_>>» 

enter conditional 



Case 1 : 
<assert 



enter overall 

X becomes 

<goal 



consequent 

v 

! 7 <is v ! f <reverse 1 »> 



<assert ! f <not !•.<* {) uj>» 



Case 2: 
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<assert !•<* v_1 (!«<1 u_> 
<assert ! f <- u 1 ! f <rest u 
<goal !»<is 

( 

! f <1 u > 



! • (value 
>» 



v}}» 
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! f {reverse !«<sub 1_ u_>}) 
!*<re verse ~ 

! f <sub 

1_ 

! f <rest u_»>» 

Alloiring shared side effects in structured data considerably 
complicates the process of proving intentions. 

7.1.2 Hodels in Patterns: Alas 

Aims are like intentions except that they are actors and occur 
in patterns. 

<AIB predecessor pattern down up successors> is the form for a 
call to the actor aim. An aim will be said to be attained when the 
following conditions are satisfied: 

[1] Its predecessor evaluates to true 

[2] He apply the function down with two arguments. The first 
is the expression to be watched. The second is <> if and only if 
pattern doesn't latch. 

[3] He apply the function up with two arguments* The first 
is <> if and only if the rest of the pattern doesn't match. The 
second is <> if and only if pattern fails. 

[4] The successors evaluate to true. 
The function down expresses the intent of the downward action of the 
pattern and the function up expresses the upward going action. The 
actor <AIHI8G [declarations] predecessor pattern down up successors> 
is exactly like the actor AIH except that intention variables may be 
declared. For example the aim in the folowing expression is 



t 



r^ 
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attained: 



<aining [[OLD-F .f]] 

_f 

<f unction [X Y] 

<assert !»<eq .f .X» 
<assert !»<is? . Y t>» 
<f unction [X Y] 
<cond 

[6<goal !«<is? .X <>» 

<assert ! »<eg .£ .OLD-F» 
<assert !»<is? .Y []»] 
[S<goal ! «<is? .X t» 

<assert !»<eg .£ .X» 
<assert !»<is? .▼ t» ]>» 

The value of £ changes only if the rest of the natch succeeds. The 
actor <ENTIfiE [declarations] predecessor pattern down up successors> 
is exactly like the actor AIMING except that it is used to express the 
entire intent of the pattern. For exanple for the actor ATOMIC which 
takes no arguments and Batches only ate is can be characterized by: 

<def ine atonic <actor [ J 
<entire T] 

<atonic> 
<f unction [X Y] 
<co»d 

[8<goal !*<aton .X» 

< assert !»<is? .Y t»] 
[6<goal !»<not ! «<aton .X>» 
< assert !«<is? .Y <»>]» 
<f unction [X Y] 

<assert !«<is? .X • Y»»» 

7.1.3 Models of PL AH NEB Theorens 



S ^. 
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We shall construct models for EIANNEB theorems in much the 

same manner as for MATCHLESS patterns* 

<THINTENT predecessor x down up successors> is true if the 
following conditions are met: 

[1] the predecessor is true* 

[2] We apply the function down with two arguments: The first 
argument is <> if and only if the evaluation of x fails. If the first 
argument is not <> then the value of the second argument is the value 
of x* 

[3] We apply the function up with four arguments* The first 
is <> if and only if the rest of the computation fails. If the first 
argument is <> then the second argument is the message of the failure. 
The third argument is <> if and only if the evaluation of x fails. If 
the third argument is not <> then the fourth argument is the value of 
x. 

The function THIHTENE is exactly like the function THINTEHT 
except that a declaration of intention variables must be the first 
argument. For example the folliwng intention is always satisfied: 
Becail that the function ASSEBT1 will assert a statement if has not 
already been proved. 



<thintend [[already-proved <>]] 

<assert1 [subset a b]> 
<f unction [X K] 
<cond 

[8<goal [proved [subset a b]]> 
<assert ! f <is? .X <>» 
<_ : already-proved t> 
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<assert !»<is? .T <>» ] 

[6<goal ! f <not [proved [subset a b]]» 
<assert [proved [subset a b]]> 
<assert ! »<is? .X t» 
<assert !»<is? .1 [subset a b ]» ]» 
<f unction [X Y U V] 
<cond 

[<is? <>> ;.already-proved> 
<cond 

[6<goal !«<is? .X <>» 

<erase [proved [subset a b ]]>]>]> 
<assert !«<is? .0 .X» 
<assert !»<is? .V .Y»» 



/"> 
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7.2 Teaching Procedures 



Crucial to our understanding of the phenomenon of teaching is 
the teaching of procedures. Understanding the teaching cf procedures 
is crucial because of the central role played by the structrual 
analysis of procedures in the foundations of problem solving. How can 
procedures such as multiplication, algctraic simplification, and 
verbal analogy problem solving be taught efficiently? Cnce these 
procedures have been taught, how can most effective use of them be 
made to teach other procedures? In addition to being incorporated 
directly as a black box, a procedure which has already been taught can 
be used as a model for teaching other procedures with an analogous 
structure. One of the most important methods of teaching procedures 
is telling. For example one can be told the algorithm for doing 
symbolic integration. Telling should be done in a high level goal- 
oriented language. PLANHEB goes a certain distance toward raising the 
level of the language in which we can express a procedure to a 
computer. The language has primitives which implement fundamental 
problem solving abilities. Teaching procedures is intimately tied to 
what superficially appears to be the special case of teaching 
procedures which write procedures. The process of teaching a 
procedure should not be confused with the process of trying to get 
the one being taught to guess what some fclacX box procedure really 
does [as is the case in in sequence extrapolation for example]. The 
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teacher is duty bound to tell anything that light help the one being 
taught to understand the properties and structure of the procedure. 
We assume that the teacher has a good model of how the student thinks. 
Also, just because we speak of » teaching", we do not thereby assume 
that anything Jike what classically has been called learning is taking 
place in the student. However, this dees not exclude the possiblity 
that the easiest way tc teach many procedures is through examples. He 
can give protocols of the action of the procedure for various inputs 
and enviroaents* By "variablization" [the introduction of identifiers 
for the constants of the examples] the protocols can be formed into a 
tree. Then a recursive procedure can be generated by identifying 
indistinguishable nodes on the tree. We call the above procedure for 
f"^- constructing procedures from examples the procedural abstraction of 
protocols. Procedural abstraction can be used to teach oneself a 
procedure. 

7.2.2 By Procedural Abstraction 

7. 2. 2. a Examples of Procedural Abstraction 

7.2.2.4.1 Building a Wall 

We shall explain procedural abstraction in more detail using 
the example of building a wall. We define <brick-at jw] |hi> to mean 
that there is a brick at the location with width |w| and height |hj 



BUILDING WALLS 



(+.2) 



(*.D 



<*,*> 



[WALL I 2] 



( + .1) 



(<*> *) 



(1,1) 



(I.*) 



[WALL 2 I] 



note: the numbers in the boxes represent 
the coordinates of the bricks. 
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and define the statement [vail Jw| JhJ] to mean that there is a wall 
of width w and height h using the definition 

<define wall <f unction [w h] 
<conjunction [[wv 0]] 

[-'"inc 11 ww -"•"by* 1 -'"thru* .w] 
Conjunction [£hh .hj] 

[-."dec* hh v*by H 1 ^"thru" 0] 
<brick-at .vv •hh>»» 

Thus <wall 1 2> means 

<and 

<and 

<brick-at 2> 

<brick-at !> 

<brick-at 0» 
<and 

<brick-at 1 2> 

<brick-at 1 1> 

<brick-at 1 0>». 

Notice that the syntactic definition of a wall runs orthogonal to the 
way in which a wall has to be constructed* Thus we could not use 
purely syntax directed methods to construct walls. The predicate 
<ASSIGNED? var> is true only if the identifier var has been assigned a 
value. 

<define build-tower 
<consequent build 

[[!=fix w h] [actions []]] 
[brick-at ?w ?h] 
<cond 

[<not? <assigned? h» 
<_ .h 0>]> 
<cond 

[<current? [brick-at ?w ?h ]> 
<. build {)> 

;"exit .build with {) ]> 
[<is? .h 0> 

<• build <!«<put- brick-at ?w ?h>)>]> 
<_ tactions <gcal [brick-at ?w <- .h 1> ]» 
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<goal [put-brick-at ?w ?h]> 

<goal [check-brick-at . w .h]> 

<assert [ brick-at .w . h]> 

<. build (i. actions ! •<put-brick-at .v .h>)» 

If we give P1ANNBB the task cf constructing a [wall 1 2], then the 
actions that will be taken are: 

<put-brick-at C 0> 

<put-brick-at C 1> 

<put-brick-at 2> 

If the goal is [vail 2 1] then the actions are: 
<put-brick-at C 0> 

<put-brick-at 1> 

<put-brick-at 1 0> 

<put-brick-at 1 1> 

He shall use tfce expression new 5 to Bean that a new identifier is 
bound and initialized to 5. He shall use the expression <value 9> to 
mean a reference to an identifier whose value is 9; the expression 
<alter 3 7> means that an identifier with value 3 is altered to be the 
value 7. Hore precisely, the protocol for [vail 1 2 ] is 



<new [ 1 21 

<new [UNASSIGNFD ONASSIGNED] 

<_ <alter UNAS SIGNED C> 0> 
<is? <value 0> <value 1» IS FALSE 
SO 

<_ <alter UNASSIGNED C> 0> 
<Is? <value 0> <value 2» IS FALSE 
SO 

<put-brick-at <value 0> <value 0» 
<_ <alter 1> <♦ <value 0> 1» 
<is? <value 1> <value 2» IS FALSE 
SO 

<put-brick-at < value 0> < value 1>> 
<_ <alter 1 2> <♦ <value 1> 1» 
<is? <value 2> < value 2» IS TRUE 
SO 

<_ <alter 1> <* <value 0> 1» 
<is? <value 1> < value 1» IS TBOE 
SO 
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The protocol for [ wall 2 1] is 
<new [2 1] 

<new [UNASSIGNED ONASSIGNED ] 

<_ <alter UNASSIGNED 0> 0> 

<Is? <value 0> <value 2» IS FALSE 

SO 
<_ <alter ONASSIGNED 0> 0> <is? <value 0> <value 1» IS FALSE 
SO 

<put-brick-at <value 0> <value 0>> 
<_ <alter 1> <♦ <value 0> 1» 
<is? <value 1> <value 1>> IS TRUE 
SC 

<_ <alter 1> <♦ <value 0> 1» 
<is? <value 1> <value 2» IS FALSE 
SC 

<_ <alter 1 0> 0> 
<is? <value 0> 1>IS FALSE 
SO 

<put-brick-at <\ralue 1> <value 0» 
<_ <alter 1> <«■ <value 0> 1» 
<is? <*alue 1> <value 1» IS TBOB 
SC 
<_ 
f~\ <alter 1 2> 

<♦ <value 1> 1» 
<is? 

<value 2> 

<valae 2» IS TBOE 
SO [ ]» 

The protocol for [ wall 2 2 ] is 
<new [2 1] J 

<ne« [UNASSIGNED ONASSIGNED] 

<_ <alter UNASSIGNED 0> 0> 

<is? <value 0> <value 2>> IS FALSE 

SO 

<_ <alter UNASSIGNED 0> 0> 

<is? <value 0> <value 2» IS FALSE 

SO 

<put-brick-at <value 0> <value 0» 

<_ <alter 1> <♦ <value 0> l» 

<is? <?alue 1> <value 2» IS FALSE 

SO 

<put-brick-at <value 0> <value 1» 

<_ <alter 1 2> <♦ <value 1> l» 

<is? <value 2> <value 2» IS TRUE 

SO 

<_ <alter 1> <♦ <value 0> 1>> 

<is? < value 1> < value 2» IS FALSE 



/^. 
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SO 

< <alter 2 C> 0> 

<is? <value 0> <value 2>> IS FALSE 

SO 

<put-&rick-at 1 0> 

< <alter 1> <♦ <value 0> 1» 
<is? <value 1> <value 2» IS FALSE 
SO 

<put-brick-at <value 1> <value 1.» 

< <alter 1 2> <♦ <value 1> 1» 
<~ <alter 1 2> <+ <value 1> t» 
<is? <value 2> <value 2» IS TROE 
SO 

[]» 

By introducing identifiers fcr the constants and by tracing the 
bindings of the identifiers of BUILD-TCWER the protocols can be 
arranged in a tree as follows: 

new [w h] 

new [ww^ONASSIGNED; hh^UNASSlGNED ] 

<_ :ww 0> 

if <is? .i« .w> 

then 

[] 
else <_ :hh 0> if <is? .hh .h> 

then 

<_ :ww <♦ .ww 1» 

if <is? ,ww „w> 
then 

[3 
else 

< :hh 0> 

if <is? .hh 0> 

then 

<_ :ww <♦ .ww 1» 

~ if <is? .ww .w> 

then 

[1 
else... 

else... 
else 

<put-brick-at .ww .hh> 
<_ :hh <♦ .hh 1» 
if <is? .hh .h> 
then 

<_ :ww <♦ .ww 1» 
if <is? .ww 1> 
then 
[) 
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else 

< :hh 0> 
if <is? .hh .b> 
then 

<put-brick-an ,ww .hh> 
< :hh <♦ .hn 1>> 

if <is? .hh .h> 
then 



<_ :vv <♦ «vv 1» 
if <is? «vw .w> 

then [ ] 
else* . . 
else. . * 



/""N 



else. . . 
e lse 

< :hh <♦ .hh 1» 
if <is? .hh .h> 
then 

<_ : ww <♦ «v¥ 1>> 

if <iS? .WW .W> 

then [ ] 
else. .. 
else. • , 



He define the protocol of an evaluation to be a list of the 
events and the places in the program where they happen that occur when 
the evaluation is being carried out. By examining the protocols of 
the system as it tries to build a vail we find that it always uses the 
same procedure. Of course it will not always be the case that the 
protocols from the solutions of the instances of a goal can be 
combined into a procedure. The basic idea is to combine the set of 
protocols into a tree and then consider any two nodes of the tree 
which cannot be distinguished on the basis of the protocols to be 
identical. In ether words it is necessary to compute a minimal or 
almost minimal homomorphic image of the set of available protocols. 
Unfortunately it is often difficult to extract the information needed 
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to do procedural abstraction from the protocols produced by PLANNER 
theorems as they solve problems. The procedure that the theorem is in 
fact using can be expressed as follows; 



<define compile- build <£ unction [w h] 
<overall [ ] 

! ;<intention [ ] 
<and 

<goal !*<is? ! f <non-neg> . w» 
<goal !«<is? ! f <non-neg> . h»» 
<and 

<assert ! f <is? ! f <non-neg> . w» 
<assert !»<is? ! f <non-neg> . h>»> 
<repeat column 
[[ww 0]] 
! ; <intention [ ] 

<goal [wall *ww .h]> 
<assert [wall «ww .h]>> 
<cond 

[<is? .ww .w> 

<intent <wali .w .h>> 
<.coluan> 
; w exit •column" ]> 
<repeat height [[hh 0]] 
! ;<intenticn [ ] 

<goal [column .vv .hh]> 
<assert [column .ww •hh]» 
<cond 

[<is? .hh .h> 
<.height> 

;*exit .height with <> w ]> 
!;<intent <goal [support-for . ww •hh]» 
<put-brick-at ,wv .hh> 
!;<intent <goal [brick-at .ww .hh]» 
<_ :hh <♦ .hh 1>» 
<_ :ww <♦ .ww 1>» 
<f unction [X] 

<assert [wall .w •h]> 
<goal [wall .w •hj»» 

<define check- wall 
< consequent 

check-wall 

[w« w fa» h] 

[wall ?w f ?h f ] 

<cond 

[<or? 
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&<goal ! »<is? ?h« 0» 

S<goal l'<is? ?w f 0»>] 
[<is? !•<♦ ?b 1> .h*> 

<goal [wall ?w f .h]> 

<goal [column ?w f ?h f ]>] 
[<is? !•<♦ ?w 1> .w«> 

<goal [wall ?w .h* ]> 

<goal [column ?w f ?h»]>3 
[-•"else" 

<fail <> .check-wall>J>» 

<define check-column 
<conseguent 

check-column 
[w h h f ] 
[column ?w ?h f J 
<cond 

[S<goal ! f <is? ?h f 0»] 
[<is? !•<♦ ?h 1> .h f > 

<goal [column ?w ?h]>] 
[^"else" 

<fail <> .check-coluan>]>» 

<define check-support 
^*^ <conseguent 

check-support 

[w h] 

[support-for ?w ?h ] 

<cond 

[6<goai !«<is? ?h 0»] 

[<goal [cclumi* .ww .hh]>] 
[ ^ f, else w 

<fail <> . check-support>]»> 

<define put-brick-at 
<f unction [w h ] 
<overall [ J 

<goal [support-for . w • &]> 
<put-brick-at • ¥ *h> 
<assert [ brick-at • * .h]»» 

The IHTENDEfi protocol for the verification of the intentions 
of coapile-build is: 

<assert ! • <is? ! f <non-neg> w_» 
<assert ! f <is? ! f <noa-neg> h~» 
eater intentions of repeat ~ 
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Case 1: initial entry 
<assert !«<is? ww_» 
<gcal [wall h_]> 

enter intentions of check-wall 
w f becomes 
h 1 becomes h_ 
<goal ! f <is?~h_ 0» 
FAIL 
<goal !'<is? 0» 

Case 2: Inductively assume 
<assert [wall ww_ n_ ]> 
enter conditional 

Case 1: 

<assert !«<is? w_ ww_>> 

<goal [wall w_ h_]> 

Case 2: 

<assert ! # <not ! f <is? w_ ww_>» 

enter intentions of repeat 

Case 1: initial entry 
<assert ! f <is? hh_>> 

<goal [column wv_ hh_]> 

enter intentions of check-column 

w beco mes ww_ 

h 1 becomes hh_ 

<goal !«<is? hh_» 

Case 2: inductively assume 
<assert [column ww_ hh_ ]> 
enter conditional 

Case 1 * 

<assert !*<is? hh_ h_» 

<assert !*<is? ww_1 !*<♦ ww_ 1>» 

<goal [wall ww_1 h_]> 

enter intentions of check-wall 

w f becomes ww_1 

h 9 becomes h 

<goal !»<is?~! f O ?h 1> h_1» 

w becomes w_ 

<goal [wall~w«_ h_]> 

Case 2 * 

<assert I^not ! f <is? hh_ h_>» 

<goal [support-for ww^ hh_]> 
enter intentions of check-support 
w becomes ww 
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h becomes hh_ 
<goal [column ww hh ]> 
<assert !«<is? hh_1 ! f O~hh_~1>» 

<goal [column ww_ hh_1 ]> 
enter intentions of check-column 
w becomes ww_ 
h 9 becomes hh 1 

<goal ! f <is? !•<♦ ?h 1> hh_1» 
h becomes hh_1 
<goal [column ww_ hh_1]> 

Note that the above proof that CCHPILE-BUILD meets its 
intentions is relative to the PROCEDURAL MODEL that we have 
constructed* The procedural model is constructed out of procedures 
such as PUT-BHICK-AT* The procedural model is connected to our goal 
oriented language by CORRESPOHBENCE BOIES such as CHECK-SOPPORT. 

The structure of the abstracted procedure must at least 
reflect the structure of the PLAHNER theorems from which it has been 
abstracted* Thus the abstraction of a for-proved loop will generate 
a recursive equation which might be simplified to a loop* Some of the 
recursion in abstracted functions is primarily generated by the 
structure of the data cf the problem* If we consider the tags column 
and height to define functions* then the proof is essentially by 
recursion induction* In the above procedure *w is the width of the 
wall to be built, *ww is a running index over the width, .h is the 
height, and . hh is a running index over the height. Osing the 
intentions in the above procedure as subgoals we can easily see that 
the procedure does build walls* Notice that we can use the protocols 
of the procedure [in a process that we call "protocol rejection" J to 
reject false subgoals in much the same way that Gelernter used 
diagrams in his geometry theorem prover. For example we might 
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evaluate <compile-build 1 2> # <compile-fcuild 2 1>, and <ccmpile-build 
3 2> remembering the trctoccls f the evaluations* Thus when 
considering the case where the intention 

<intent 

<or 

<is? ««<v 0> 

<wall <sub1 .ww> . hh>» 

is evaluated immediately after <end column> is evaluated, it will be 
the case that <is? .ww 0> is false and so cannot possibly be a 
provable subgoal even though it implies the intention. The subgoal 
will be to prove [implies <not <is? .w 0» <wall <sub1 ,ww> .hh>]. Of 
course using protocols for the purpose of rejecting false subgoals 
does not help us to eliminate those that are true but unprovable. 

7.2.2.4.2 Beversing a list at All Levels 

Consider the following protocols for a procedure r: 



<new Ta] 

<is? <monadic> <value a»> IS TB01 

SO <value a> 



thus <r a> is a 



<new [[n]] 

<is? <monadic> <value [n]» IS FALSE 
SO 

[ 

{new [<rest <value [n]»] 
<is? <mcnadic> <value [ ]» IS TBUE 
SO <value [ ]>} 
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<new [<<value £ n ]> 1>] 
<is? <monadic> <value n>> IS TBUE 
SC <value n>>]> 

thus <r £n ]> is £ n ] 

<new [[a b]] 

<is? <aonadic> <value [a b]>> IS FALSE 
SO 

i 

{new [<rest <value [a b]>>] 

<is? <aonadic> <value [b]» IS FALSE 
SO 

[ 

{<new £<rest <value [b]>>] 

<is? <Bonadic> <value £ ]» IS T80E 

SC <value [ ]>>} 
<new £«value [b]> 1>] 
<is? <ionadic> < value b>> IS TBUE 
SC <value b»]} 
<new £<<value (a b}> 1>] 
<is? <aonadic> <value a» IS TBUE 
SC <value a»]> 

thus <r [a b]> is [b a] 



<nev [[[a]]] 

<is? <nonadic> <value [[a]]» IS FALSE 
SO 

C 

(<nev [<rest < value [[a]]»] 

<is? <ncnadic> <value £ ]» IS TRUE 

SO [ ]>} 
<new [« value £[a]]> 1>] 
<is? <ncnadic> <value £a]» IS FALSE 

SO 

£ 

(<new £<rest < value [a]»] 
<is? <Bonadic> < value £ ]» IS TBUE 

SC [ ]>} 
<new [« value £a]> 1>] 
<is? <Bonadic> < value a>> IS TRUE 

SO <value a»]>]> 

thus <r ££a]]> is ££a]] 

We obtain the following prctoccl tree: 
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<new [ x1 ] 

if <is? <aonadic> .x1> 

then .xl 
else 

[ 

(new [ x2 <rest .x1>] 

if <is? <aonadic> . x2> 

then .x2 

else 

[ 

(new [x3 <rest .x2>] 

if <is? <mcnadic> .x3> 
then .x3 
else.*.} 
<nev [x4 <1 .x2>] 
if <is? <©cnadic> .%**> 
then *x4 
else. ♦ ♦>]) 
<ne* [x5 <1 .x1>] 
if <is? <acnadic> .x5> 
then .x5 
else 

[ 

{new [x6 <rest •x5>] 
if <is? <mcnadic> . x6> 
then .x6 
else* . .} 
<new [x7 <1 .x5>] 
if <is? <aonadic> .x7> 
then *x7 
else* .•>]>]> 



By identifying indistinguishable nodes «e obtain: 

<define su per- re verse <f unction [x] 

<cond 

[<is? <acnadic> .x> 

• x ] 
[-*"else w 

[ 

{super-reverse <rest . x>} 

< super- reverse <1 •x»]]»> 
7.2.2.4.3 Finding the Description of a Stick 



r^. 
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Suppose that we have the following data base: 
[block a] 
[block b] 
[glued a bj 

The above data base represents a stick on the the basis of the 
following protocol: 

<goal [stick a bj> 

<new [UHtfSSIGHED OHASSIGHBD OHASSIGHED] 

values" ; " W * haVe three ae " idcntifie " that do not have 

consequent: [stick <given OHASSIGHED a> <given OHASSIGHED b>] 

<current [glued <given a> <given b>l> 
<return t>> J 

How suppose that the data base is: 
[ block a ] 
[block b] 
[block c] 
[glued a b] 
[glued be] 
[between a b c] 

He obtain the following protocol: 

<goal [stick a cj> 

[new ONASSIGHED OHASSIGHED OHASSIGHED 1 
conseguent: [stick <given a> <given c>1 
cond * 

<current [glued <given a> <given c>]> 

<current [block <given a>]> 
<goal [glued <value a> < OHASSIGHED b>]> 
<current [between < value a> <value b> <given c>l> 
<goal [stick < value b> < value c>]> J 

[new OHASSIGHED OHASSIGHED OHASSIGHED J 
consequent: [stick <given b> <given c>] 
cond 

<proved [glued <given b> <given c>l> 
<retura t> * 




[block a] 
[block bl 
[glued a b] 

FIGURE I 



a b c / 

* 



[block a] 
[block b] 
[block c] 
[glued a b] 
[glued b c3 
[between a be] 

FIGURE 2 



[block a] 
Cblock bl 
[block c] 
[glued a b] 

[glued be] 

[not [between a b c]] 



c / 



FIGURE 3 
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By variabalization we obtain the following protocol tree: 

<goal [stick u v ]> 
[new x y z] 

consequent cl: [stick ?x ?z] 
<cond 

[6<goal [glued ?x ?z ]> 

<.d t> 

;"exit ,d with t" ]> 
<current [block ?x ]> 
<goal [glued .x _y]> 
<current [between .x .y ?z ]> 
<goal [stick .y .z ]> 

[new x1 yl zl] 

consequent c2: [stick ?x1 ?z11 

<cond 

[6<goal [glued ?x1 ?z1]> 

<.c2 t> 

; M exit .c2 with t« ]> 
<current [block ?x1]> 
<goal [glued .x1 _y1 ]> 
<current [ between". x1 ,yl ?z1]> 
<goal [stick .yl .zl ]> 

By identifying indistinguishable nodes we obtain the following 
consequent theorem which is the description of a stick. 

<define stick-description <ccnseguent c 

[stick ?x ?z] 
<cond 

[6<goal [glued ?x ?z1> 

<.c t> 

;"exit ,c with t"]> 
<current [block ?x]> 
<goal [glued ,x _y]> 
<current [between .x .y ?z]> 
<goal [stick .j .z]>» 



7.2.2.«l.a Finding the fibonocci ambers Iteratiwely 
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Soaetiaes it is possible to iaprove the efficiency of a 

procedure by procedural abstraction. Tor exaeple consider the 

protocols of the scheaa f defined below. 

<define f <f unction [n] 
<cond 

[<or <P .n> <P <S .n>» 

<OHE>] 
[-* w else w 

<1 <f <S .n» <f <S <S ,n»»]>» 

He shall used the abbreviation that <f-0 x> is x "d <f-n*1 *> * s <f 
<f-n x» where f is a function. Thus <f-2 x> xs <f <f r». The 
protocol for the above scheaa is: 

if <or <P <S-«0 n» <P <S-1 n>» 
then <OHE> 
else 

if <or <P <S-1 n» <P <S-«2 n>» 
then <OHE> 
else 

if <or <P <S-2 n» <P <S-*3 n>» 
then <CBE> 

if <or <P<S-*3 n» <P <S-.4 n>» 
then <OHE> 
else...> 
if <or <P <S-2 n» <P <S-3 n>» 
then <CEE> 
else 



<& 



if <or <P <S-3 n» <P <S-.4 n>» 

then <OHE> 

else... 
if <or <P <S«.«I ns> <P <S-»5 n>» 

then <0»E> 

else...» 



By procedural abstract io* we can obtain a function f 1 which is 
equivalent to f. xhe function is obtained by identifying some or the 
nodes that are not on the saae branch of the protocol tree. 
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<define f <f unction out [nl 
<cond J 

£<or <P . n> <p <s ,n»> 

<.out <OHE> <CHE»3 
[-* w else w 
<call 

<f <s .n» 

<f unction [downl down2 ] 
<.out 

<A .downl .down2> 
.down1>»]>» 

Another approach is to use scie of the theory of recursive scfaenas. 
The function f defined above is schematically equivalent to the 
function ff defined below 



<define ff <f unction ff f a l 
<for £[x 0] [y c/)J J 



./""> 



[[-"test- <p ,n> <.ff .*> ;«exit .ff with .x«1 
[-•"step" <_ :n <s .n»n ' 

<- t:« sy] <tuple <A .x .y> ,x» 

; K tbe previous statement is just a tricky way to 

sinultaneocsly accomplish < :x <k .x .y» 
and <_ :y .x>">» ~ * 

Mote that <fib n> the nth Fibonacci nunber can be defined as follows 

<define fib <f unction [n] 

<cond 

[<or <is? 1 .n> <is? 2 .n» 

1] 
£-» n else" 

<♦ <fib <- .n 1» <- .n 2»J>» 

Osing the interpretation that <0»B> is 1, <P x> tests to see if x is 

V and A is add, we see that the function fib can be rewritten 
iteratively. 

The process of procedural abstraction is very iach like * 
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generalized form of ccmpilation. The relationship between the 
compiled version and the interpreted version can be very subtle. In 
classical compilers the relationship is such more straightforward. 
Every time that the interpreter for the language changes the compiler 
must change. In fact the interpreter and compiler are two mooes of 
what is essentially cne prograi: an interpreter-compiler. In compile 
mode it would actually produce the coipiled code for the source code; 
in interpret mode it would take the actions corresponding to the 
compiled code that would be produced in compile mode. The 
interpreter-compiler can be written it MATCHLESS so that in compile 
mode the HATCHLESS skeletons have as value the compiled code. One 
problem with interpreter-compilers is that they suffer from the 
inefficiency of double interpretation. Instead of directly 
interpeting the expressions, in interpret mode the interpeter-compiler 
interprets the skeletons that would produce the code in compile mode. 
The problem can be solved by compiling the interpreter-compiler for 
interpret mode. He would like to try to extend this idea to PLAINER 
in a more nontrivial way so that joals would be created to produce the 
compiled code. 

7.2.2.4.5 Defining a Data Type 

He can do procedural abstraction of protocols along the same 
lines for actors. For example if we obtain th« following actor 
protocol 



/"**% 
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[<when 



[<atoaic>] 
[<when 



{when 



[<atoiaic>] 
[<when 

an 

[<atc«ic>]>]> 

[<atoaic>] 
[<when 

[£]] 

£<atoiic>] 

[<vhen 

[£]]> 
{when 

tin 

[<atoaic> ]}]>]}]>] 
/^N Then by identifying equivalent nodes we obtain the actor expr where 

<define expr <actor £ ] 
<when 

tin 

[<atonic>] 

t£<expr> (expr}]]>» 

Goodstein has nany inductive proofs of the the properties of 
recursive prograns. John HcCarthy was one of the first to popularize 
the use of recursion induction for proving tbe properties of progra.s. 
The easiest way to do recursion induction is to provide at least one 
predicate for each recursive equation, fiobert Floyd has proposed that 
predicates in the first order guantificational calculus be attached to 
the edges of flow charts in order to provide subgoals for proofs of 
properties of prograis. in general we would prefer to proceed .ore 
^ constructively and to write intentions in PUHHBB rather than in a 
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form of the quantif icational calculus. Finding an intuitionistic 
proof of a sentence in first order logic is the saie problem as 
finding a recursive function that realize the the formula. Since the 
logistic system of PLAHNEB is very constructive, a proof of a PLAHHEB 
theorem entails being able to write the procedures which compute the 
values that identifiers in goals take en as a result of the goal being 
established. Intentions are a first step toward constructing models 
of the environment in which a process executes. He need to develop 
good ways to increase the expressive power of intentions. Currently 
the iodel of tee computation must be expressed by intentions within 
the process being executed which makes it difficult to get a global 
view of the model of the execution of the process. The application of 
intentions in which we are most interested is their use to provide 
subgoals to enable us to deduce PLAHHEB theorems with loops in them. 
He shall say that an intenticn i characterizes a function f if 
whenever <f x> converges then <equal <f x> y> if and only if <i x y> 
is true. A long time ago John HcCarthy and others proposed that tne 
debugging problem be solved by proving that the procedure is correct 
once and for all. Using induction HcCarthy and his students have 
proved that certain compilers are correct. The most important 
practical difficulty to the realization of the proposal is that for 
many functions f written in higher level languages it seems that all 
the intentions that characterize f are at least as long as f because 
the only way to tell whether the value of <f x> is correct or not is 
to do an equivalent computation all over again. A good example of 



f~\ 
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such a function is eval in LISP. The function eval is an extreme 
example of a function that has no simple declarative input ouput 
characterization. a real challenge in automatic prograa writing is 
to develop a symbolic inetegration routine from the criteria that the 
derivative of the answer must be equivalent to the input. One 
approach toward constructing such a routine would be to maXe use of 
some results of aisch on what aust be the form of the integrand as a 
function of the form of the integrand. In the case of the factorial 
function there are two obvious ways to compute the function: using 
recursion or using a loop, in other cases it is not so obvious how to 
find a sufficiently different equivalent program. He shall say that 
an intention i is implied by a function f if whenever <f x> converges 
f-s then if <egual <f x> y>, then <i x y> is true. Implied intentions are 
useful when we are only interested in some property of the function 
and don't care to try to characterize it completely. For example we 
might not care whether a function that determines how to stack cubes 
always puts red cubes on the bottom of the tower that it is trying to 
build. or we might be interested in proving that a scheduler for a 
time sharing system passes some test for fairness in its distribution 
of time to users. Another potential use for implied intentions is to 
provide subgoals to prove that a given function that uses lock and 
unlock and unlimited use of assignment in parallel computations is 
indeed determinate. 

A mora serious problem is that often we cannot develop 
reasonable implied overall intentions, consider trying to write 
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intentions for a chess program. We could require that the program 
play LEGAL chess but this is the least of considerations. How can we 
write intentions to the effect that the program should play GOOD 
chess? There is a completely trivial program which will play PERFECT 
chess given sufficient time and storage. However, the amount of time 
and storage reguired are wildly impractical. One might believe that 
the problem of writing overall intentions afflicts only game playing 
programs. However, the same problem arises in trying to write 
overall intentions for a robot. He can specify in detail a certain 
finite number of eletertary procedures which the robot should be able 
to perform. In a given situation there may be some obscure way for 
the procedures to interract to provide a solution for a problem. 
However, it is not fair to blame the robot for not solving a very 
difficult problem. Thus we again have a problem writing realistic 
overall intentions, 

7,2.3 Teaching Procedures by Deducing the Bodies of Canned Loops 

If the type of control structure is known a priori, then the 
rest of the function can often be deduced. Often the control 
structure needed is a very commonly used loop such as the FOB loop in 
MATCHLESS, recursion on the tree structure of lists, or one of the 
loops in PLASHES such as TBI, ?1HD, or EXHAUST. We shall call loops 
such as the above "canned 19 loops since we will often pull them out and 
use them whole when we are in need of a control structure for a 
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routine. The approach of using canoed loops is the one used by 
Kleene for constructive realization functions for intuitionistic 
logic. Suppose that He know the following theorea about the 
predicate [REVEBSB? x y] which leans that y is the reverse of x. For 
example [reverse? aa aa] and [reverse? [1 2 [3 i|]][[3 4] 2 1)] are 
true. As before • is used to suppress invocations, and a nonad is 
defined to be an atom, a number, [ ], or [ J. The function IDENTITY 
which is used below is the identity function. 



<define th69 <conseguent 
[a b c] 

[reverse? ?a ?b ] 
<cond 

[<hasval? a> 
<cond 
/"-"N [6<goal !»<aonad? .a» 

; M if a is a aonad then b should be egual to a" 
<goal !»<is? .a ?b»] 
[-'"else" 

<goal !«<not !»<nonad? ,a»> 

<goal [reverse? !«<rest ,a> _c}> 

; "otherwise let c be the reverse of the rest 



of a" 



<goal !«<is? [•{identity .c} !«<1 .a>] ?b»j>] 
[-"else" <fail>]>» J J 



f^x 



le would like to find a function reverse such that [reverse? x 
[reverse x]} is always true. The theorea above suggests that we try 
to use linear induction on lists as the control structure. The scheaa 
for .linear induction applied to the function reverse is: 



<define reverse <f unction [xl 
!«<cond * J 

[ !*<aonad? ,x> 

<teaprog [I] 

< assert !'<aonad? .x» 
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<gcal [reverse? ,1 Jl ]> 
i ; w find a I which is the reverse of the monad 
x and return it as value 11 

£-t*else* 

<teaprcg C * ] 

<assert ! f <not l^aonad? .x»> 
<assert [reverse? 

!«<rest .%> 

! f <re verse ! f <rest . x»]> 
<goal [reverse? .x _*]> 
.Y>]»> 

The above expression evaluates to the following definition: 



<define reverse <f unction [x] 
<cond 

[<monad? .x> 

[-•"else 11 

[ (identity <reverse <rest .x»} 
<1 .x>]]>» 



7.2.4. Comparison of the Hethods 

Superficially considered, there is not Bach to be said about 
teaching procedures by telling. It is not always clear whether tlie 
procedure should be taught from the top down or the primitives should 
be taught first. However, the basics of the method are simple and 
direct. unfortunately the teacher will not always know the code for 
the procedure which is to be taught. Be might be engaged in wishful 
thinking hoping to find a procedure with certain properties. The 
method of canned loops is often applicable to such cases* Trying to 
use the method of canned loops has the problem that the control 
structure must be supposed. Often it is very difficult to guess the 



/O 
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kind of control structure which will prove appropriate. Also the 
method of canned loops works on the problea in the abstract as opposed 
to specific examples where the identifiers are bound to actual values. 
The advantage of the abstract approach is that if it succeeds then the 
procedure will be known by its construction to have certain 
properties. On the other hand it is often easier to see what to do 
on concrete cases. Often it is easier to show someone how to do 
something than to tell him how to do it. Partly this is because the 
descriptive language necessary has not been adeguately developed and 
so «e use "body language". The approach of procedural abstraction is 
to -oabine together several concrete cases into one suoposed general 
procedure. Properties of the general procedure must then be 
^ established by separate argument. If the protocols of the examples 
are produced by a goal-oriented language such as PlAHHBH, then there 
will be points along the protocols where certain predicates are known 
to be true. The predicates express the fact that some goal was 
established as true at that point. Often it is possible to show by 
mathematical induction that the corresponding properties in the 
abstracted procedure are always true when the procedure passes through 
the points. In this way a problem solver can have a partial model of 
his problem solving procedures. The models can be expressed naturally 
in PLANNER. Also the method of procedural abstraction has the 
advantage that the control structure does not have to be supposed in 
advance. often a problea solver will have the basic problea solving 
ability to solve any one of a certain class of problems. But he mill 
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not know that be has the capability. Hriting a procedure which can be 
shown to solve the class enables the problem solver to bootstrap on 
his previous work. Procedural abstraction itself is further evidence 
for the Principle of Procedural Embedding. To implement the principle 
as a research program reguires a high level goal-oriented formalism* 
PLANNER and some embellishments that we have made to the language are 
first steps toward realizing the Principle of Procedural Embedding. 



7.3 page 337 
7.3 Current Prcbleas and Future Work 
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Currently we have nechanisas to handle the following kinds of 
"bugs" or "local changes" in programs: 

HISIDEHTIFICATIOH of BODES: If two nodes of a protocol have 
been aistakenly identified as being the saae then the aistake can be 
corrected froa new protocols which distinguish the nodes. 

VABIAB4LIZATIGH: Procedures can be aade aore general by 
changing soae of their constants into variables. 

PATCHES: Existing routines can soaetiaes be converted into 
the desired procedure by introducing new intentions into thea. The 
patch is produced by the code generated by the new intention as it is 
evaluated by INTENDEH in the envircnaent in which it was placed, of 
course a bug is suspected at the point where an ordinary intention 
cannot be verified. 



Be need to find ways to iaprove the existing nechanisas and to 
find ways to handle other kinds of bugs and local changes. Also 
procedural abstraction aust be generaliaed to accept higher level 
protocols aifd to aake better use of existing procedural knowledge in 
doing the abstraction. 
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8. Here Comparative Schematclcgy 



Abstract 



Schemata are programs in which some of the function symbols 
are uninterpreted. In this chapter we compare classes of schemata in 
which various kinds cf constraints are imposed on some of the function 
symbols. Among the classes of schemata compared are program, 
recursive, backtrack, and parallel. 
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8.1. Analytic Theory 

8.1.1 Classes of Schemata 
8.1.1.1 Recursive Scbeaata 

The following is an inforaal progress report of soae work that 
I have done with Bike Paterson. John l. white aade iaportant 
suggestions and corrections. The result that recursive scheaata are 
aore powerful than prograa schema was obtained as a tera project in 
the spring of 1969. Rigorous proofs are not given here but just an 
indication of how a prcof would go. Progra. scheaata are nonrecursive 
/"N procedures that have uninterpreted function sy.bols and predicate 
syabols. He shall use capital letters to denote uninterpreted 
syabols. He assuae that within each co.puting do.ain that there is a 
distinguished eleaent denoted by false and that all other eleaents of 
the coaputing doaain are regarded as true in conditional expressions. 
Thus we do not need to distinguish between predicates and other 
functions. Iteration within prograa scheaata is perforaed by REPEAT 
loops. Repeats are defined so that (repeat <body» will repeatedly 
execute <body> until a (return <values» stateaent is encountered at 
which point control is transfered out of the saallest enclosing block 
with the indicated values. Blocks can be given naaes and the function 
(exit <naae> <values» will cause control to leave the naaed block 
with the appropriate values, it is easy to see that any prograa 
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schema in the sense of Patterson can be written using BEP1AT and EXIT 
with out the use of GO. Writing iterative computations using BEPEAT 
and EXIT has the advantage that all the loops are of necessity nested. 
Be shall allow schemata to use a finite number of distinguished 
objects which can be tested by the binary predicate IS. For example 
(is x "hello") is true only if x is the distinguished constant 
"hello". Functions evaluate their arguments from left to right. 
The following is an example of a program schema: 



(g x) = .^PflVPreiister cf the program schema g which is 
initialized to the value of the argument x" 

(if (or (P x) (is x "dolly")) then (return y) ) 

(x <- (1 y)) 

(y <- (R (B y)))) 

The BHF syntax for program schemata is as follows: 



program ::= <term> 
term : :* <blcck> 1 

<repeat> I 

<again> | 

<exit> 

(if <term> then <terms> else <terms>) \ 

<assignment> | 

false 1 

<literal-string> J 

<identifier> \ 

<function-call> 
block ;:* (block <body>) 
assignment ::= (<identifier> ■<-" <term>) 
repeat ::= (repeat <body>) 

function-call ::= ^uninterpreted- functxon> <arguments>) 1 
(is <term> <term>) J 

(call ^ ^» 

(<uninterpreted-function> <arguments>) 

<fanction>) 

again ::= (again) I (again <na»e>) 

exit ::* (exit <name> <terms>) I (return <terms>) 
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body ::» <naae> <declaration> <teras> | 

<declaration> <teras> 
terms ::= <tera> | <tera> <teras> 
declaration ::« (<identifiers>) 
arguaents ::= j <teras> 
identifiers ::« j <identifier> <identifiers> 

A recursive scheaa is a prograa scheaa that is allowed to call 
itself or other recursive scheaata recursively. The following is an 
exaaple of a recursive scheaa x which is defined by a set of recursive 
equations: 



(x x) * (if (P x) then x 

else (C (x x) (a (B x)))) 

(■ y) » (if (p (r y)j then <l y) 

else (C (a (1 yj ) (x (x x) ) ) ) 

^ For any recursive scne.a defined by a set of r^utsive equations we 
can construct an equivalent recursive scheaa aith cnly one equation 
and one additional arguaent to tell ahich equation is being si.ulated. 
This is possible because we allow recursive scheaata to use a finite 
nuaber of distinguished constants and predicates to test for these 
constants. The following is an exaaple of a recursive scheaa that 
uses the interpreted constant syabols true and false. 

(f x) = (if (p x) 
then 

(if <Q x) 

then true 
else false) 
elseif (f (L x)) 

then true 
else (f (H x))) 
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8.1.1.1.1 comparison with Program Schemata 

in fact the above recursive schema is not equivalent to any program 
schema. By equivalent we mean that the two schemata must both fail 
to terminate or both must return the same value for all 
interpretations of the functions P, Q, L, and R. Often we will take 
the set of uninterpreted terms as our domain of interpretation. In 
the above case the domain of interpretation is x (L x) , (B x) , {L (L 
x)), (L (H x)), (R (L x)), etc. The function letters L and B are 
interpreted as 1 and r where: 

(1 y) is defined to be the term (L y) 

(r y) is the term (ft y) 

Thus (1 (R (L x))) is the term (I (R (1 x) ) ) . Two schemata are 
equivalent if and only if they define the same function on the domain 

of terms. 

Theorem: 

The function f defined above is not equivalent to any program schema. 
Proof: Consider the following class of interpretations [I n} where n 
is a non-negative integer: 

The domain of interpretation is the set of terms that can be 
constructed from the indeterminate x and the predicate letters L and 
E. The predicate Q is interpreted as a function q with range {true 
false}. The predicate P is interpreted as the function p: 
(p (h//C ..,(h//m x)...)) = true f or m - a 
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= false other vise 
where each h//i ("h subscripted by i") is the iaterpretaU.cn for R or 
the interpretation for I and there is at most one path such that 

(q (h//0... (h//n x)...)) » true 
The domain of (I n} is the set of all terms that can be constructed 
from the indeterminate x and the functions I and B. Be are going to 
prove that for any program schema P we can find an integer t such that 
P does not define the sane function as the recursive schema f on at 
least one member of the class (I n). In the the interpretation {I 3}, 
we have the following I-B tree { where each node is a term in the 
domain of {I 3}) : 

CX «L x, 

{(L (1 x)) 

1(1 (L (L x)))} 
{(B (L (L x)))}} 

C(B (L x)) 

((L (B (L x)))> 
{(B (B (L x)))}}} 

(<B X) 

{(L (H x), 

C (i • «l (B x) ) ) } 
((B (J. «B X))>}} 

C(B (8 *>) 

{(L (B (B x)))} 
{(B (B (B X) ))}}}} 

the function p is true only oi the right-most (i.e. bottom) nodes and 
q is true on at most one of the right- most (bottom) nones. Be shall 
define the state of a program schema P at a point in its computation 
to be the contents of the registers of P together with the statement 
of P that will be executed next. Two states S1 and S2 of P under the 
interpretion I will be said to be EQ0X¥*1EST if p axecutes exactly the 



f~\. 
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same sequence of instructions when started fro. S1 as when started 
froa S2. He shall define the nuaber of stateaents of a prograa scheaa 
to be the total nuaber of left parentheses in the text of the prograa 
scheaa. Suppose we have a prograa scheaa P with s stateaents and X 
registers. In the interpretation {I n> , the prograa scheaa P has at 
aost s*((n+2j-k) equivalence classes of states where - is the 
exponential function. (Intuitively the only thing the scheaa can do 
is to count down each of its k registers to the bottoa of the 1-H tree 
and test each of thea to see if it has reached the bottoa.) However, a 
prograa scheaa needs at least 2-n steps in order to check if g is true 
on each of the nodes at level n. But after 2-n steps, P aust be in an 
infinite loop since it will have arrived at two distinct nodes of the 
^ t-B tree in the saae equivalence class of states. To see the Batter 
soaewhat differently lcox at the sequence of equivalence classes of 
states. if the sequence repeats then the prograa scheaa is in an 
infinite loop. But the prograa scheaa aust seek and test all 2-n 
terainal nodes and then halt. Therefore the prograa scheaa needs at 
least 2-»n equivalence classes. 

The Single Instance Theorea: 

I single recursive scheaatic equation that defines a function fora f 
can be transforaed into an equivalent prograa scheaa if the fora f 
appears only once in the definition of the function. 
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Proof: 

Define (F-»n x) to be F applied n tines to some argument x. 

(F-0 x) = x 

<F-(n*1) x) = (F (F-n x) ) 

Foe example {F-1 x) is (F x) and (F-2 x) is (F (F x) ) . 

Suppose the definition of f is of the form 

(f k) = if {alpha k} 

then {beta k} 

else {gamma (f {delta k} ) k} 

where falpha k} is the expression that is evaluated before the 
recursive call to f , { beta k} is the expression that is evaluated if 
there is no recursive call to f, and {gamma (f {delta k} ) k} is the 
value for a recursive call to f. The reader may or nay not want to 
examin the following tree vihich shows f partially expanded: 

{if {alpha {delta-0 k}} 
then 

{beta {delta-0 k]} 

else 

(gamma 

(if {alpha {delta-1 k}} 
then 

{beta {delta- 1 k}J 
else 

{gamma 

(if {alpha {delta-2 k}J 
then 

{beta {delta-»2 k}} 
else 

{delta- 1 k}}) 
{delta-0 k}}) 
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The function f can be re- written as follows: 

(f k) * (block {{■ <- Jc) n i j) 

. .,. ,. ;M "' n ' i ' and J ar€ registers of the program schema f; a is 
initialized to the value of k" t ■ **> 

(repeat () 

(if {alpha m} then (return)) 

(m <- (delta a})) 

(i <- k) 

(n <- (beta a} ) 

(repeat ( (i <- k) (n <- k) ) 

(if {alpha i} 

then 

(exit f n)) 

(i <- {delta i}) 

(repeat {{j <- i) (a <- k) ) 

(if {alpha j} then (return)) 

(j <- {delta j}) 

(a <- {delta a))) 

(n <- {gaaaa n a}))) 

He would like to repeat the iterative definition of f giving coaaents. 
/~\ An expression that appears within [ and ] is an intention that is 
expected to be true whenever control passes through the expression. 
It is not necessary to understand the intentions in order to 
understand the schema f. In fact many readers might prefer not to read 
the intentions. The intention functions fa, fc, and fd are intended 
to express what goes cc in loops a, c, and d respectively. 

(f k) = (block (j(a <- k) n i j) 

;"m, n, i, and j are registers of the prograa scheaa f: a is 
initialized to the value of k" 

(repeat a () 

(if {alpha a) then (exit a)) 
(a <- {delta a}) ) 

[define (fa a) - if {alpha a} then a else {delta a}] 

[(a * (fa k)) ;"lt is our intent that a be equal to (fa k) at 
this point. It can be shown by induction that this intention is 
always realized.**] 

(i <- k) 

(n <- {beta a)) 
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(repeat c ( (i <- k) (n <- k) ) 
(if {alpha i} 
then 

[ (f k) = (fc {delta {fa k)} k) = n] 
(exit £ n) ) 
[n » (f i) ] 
[define (fd n a j) = if {alpha j) then (gamma n ■} 

else (fd n {delta a} {delta j} ) ] 

[define (fc n i) » if {alpha x} then n else (fc (fd n 

k i) (delta i} ) ] 

[a = (fd {beta (fa k)} k i) ] 
(i <- {delta i}) 
(repeat d { ( j <- i) (m <- k) ) 

(if {alpha j} then (exit d)) 

(j <- {delta j}) 

(b <- (delta a} ) ) 
(n <- {gaaaa n m}) 
[n = (f m) ])) 



8-1.1.1.2 Compilation 

He can look at program schemata and recursive schemata as 
automata that operate en the universe of terms as a data space. A 
finite state schema automaton operates under a finite state control 
structure using a finite number of registers each of which can hold 
one term. As a primitive operation the automaton is allowed to create 
a term by applying a function to terms stored in its registers and 
then to store the result back in a register- In addition the 
automaton is allowed a finite number of primitive predicates to test 
the contents of its registers. The class of finite state schema 
automata is equivalent to the class of program schemata in the obvious 
way. Program schemata can be regarded as being executed by a finite 
state schema automaton after a suitable compilation. A pushdown 
schema automaton is defined to be a finite state schema automaton with 
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a pushdown stack. In addition a pushdonn schema automaton is allowed 
a finite nunber of distinguished constants as teras together with 
predicates that test for the distinguished constants. Be will 
investigate the relationship between these aachines and schemata. The 
appropriate kind of equivalence is one in which side effects are 
allowed. Two schenata will be said to be side-effect equivalent if 
they are the sane function for all interpretations including those 
which involve side effects. An uninterpreted function nay change the 
definition of any of the unintepreted functions as a side effect of 
being evaluated. For exaaple the schemata j1 and j2 below are not 
side-effect equivalent. 



/•> (J1 x) » if (P x) then x 

else (jl (pi (G x) (G x) ) ) 

<p1 x y) m x 

<j2 x) = if (P x) then x 

else (j2 (G x) ) 

The free interpretations for side effect schenata are the ones in 
which each uninterpreted function synod is interpreted is the 
function which evaluates to the list of all the primitive terns that 
have been previously evaluated in the computation. For exaaple the 
side-effect protocol tree for j2 is 



if (P x) 

then {x ♦(? x)} 
else 

if (P (G x)) 

then f(G x) *(P (G x)) (G x) -<p x)J 



/•*% 



else 
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if (P (G-«2 x) ) 

then {(G-2 x) +(P (G-2 X) ) (G-2 X) - (P (G x) ) (G 

x) - (P x) } 

else. • . 

On the other hand the side-effect protocol tree of j1 is: 

then {x ♦ (P x)} 
else 

if (P (G x)) 

then {(G x) MP (G x) ) (G x) (G x) - <P x) } 

else 

if (P (G-.2 x)) 

then {{G-2 x) +(P (G-2 x) ) <G-*2 x) (G-2 x) - (P (G 

x)) (G x) (G x) -(P x)} 

else. . . 

Thus J1 and j2 are net side-effect equivalent. 



Theorei: Side-effect equivalence is decidable for program 

schemata. 

Proof: The prcof is by tree expansion. Two program schemata 
are side effect equivalent if and only if for every execution path of 
one schema there is an execution path for the other with the 
uninterpreted functions called in exactly the same order. Given a 
cycle in one schema it is decidable whether the cycle can be embedded 
in the other- 
Conjecture: side-effect equivalence is decidable by tree 
expansion for recursive schemata. 

If this conjecture is correct then we can attach a post processor to a 
compiler which decides whether or not the compiled code is side-effect 
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equivalent with the source code. 

The BNf syntax for program scheaa automata is as follows: 



program ::= <ccamand> 
command ::= <block> | 

<repeat> | 

<again> | 

<exit> | 

<push> | 

<pop> | 

<conditional> | 

<function-call> 
value ::= false J identifier | <literal-string> 
values ::= <value> | <value> <values> 
pop ::= (pop) J (pop identifier >) 
exit ::» (exit <name> <values>) J (return <values>) 
conditional ::« (iftrue <coaaands> else <ccaaands>) | 

(ifeapty <commands> else <coaaands>) 
again ::= (again) J (again <naae>) 
push : := (push) J (push <value>) 
block ::= (block <body>) 
/""^ repeat ::= (repeat <body>) 

function-call ::= 

(call 



(call 



<nuaber-of-args> 
<uninterpreted-function>) J 



<nuaber-of-args> 

<uninterpreted-function> 
(<identfiers>) 
<coaaands>) J 
(call 2 is) 
identifiers ::= | <identifier> <identifiers> 
body ::» <aaae> <d€claration> <coaaaads> | 

<declaration> <coaaands> 
declaration ::* (declarers) 
declarers ::* | (<identif ier> <value>) <declarers> 

There are a few non-cbvious constructs in the above syntax. 
The expression (pop <identifier>) removes the top eleaent froa the 
stack and makes it the new value of the identifier, arguaents to 
function are passed on the stack and the results are returned on the 
stack. 
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The Compilation Theorem: 

For every recursive schema there is a side-effect equivalent pushdonn 
schema automaton. 

Proof: 

Be shall shon ho* to compile the schema f defined belon: 

< f X) " ; ( SJ°5s i'Li'lccalHlich is initialized to (H x) « 

(if (P x) 

then (K z y) 
else if (ana y (P (f x))) 

then (K 7 x) 

els« (G (K y x) y))) 

The compiled fori is 

(f x) = (block ((y false)) 
(posh x) 
(call 1 H) 

(pop 7) 

(push x) 
(call 1 P) 
(iftrue 

(pop) 
(push x) 
(push y) 
(call 2 K) 
(return 1) 
else 

(pop) 
(posh y) 
(if true 

(pop) 
(push x) 
(call 1 £) 
(call 1 p) 
(iftrue 

(pop) 



8e 1. 1 # 1 page 352 









(push 


y) 










(push 


*) 










(call 


2 


*) 








(return 


D 




else 


i 












(pop)) 






el 


se 

(push 
(push 


Y) 
x) 










(call 


2 


K) 








(push) 












(push 


7) 










(call 


2 


G) 








(return 


D))) 







8.1.1.1.3 Scheaata with Besets 

Tags can be thought of as identifiers which are bonnd at each 
activation level. By passing the activation as a paraaeter the level 
f~\ of activation can be iaaediately reset by executing a transfer ot 
control through the activation, in order to obtain an eguivalent 
machine, we can extend the instructions of the push down scheaa 
automaton by allowing thea tc store a pointer to the top element of 
the stack into one of the registers. The resulting class of aachines 
is called the reset push down scheaa autoaata. if the stack is ever 
popped back past a location that is pointed to by a register then the 
autoaaton halts with an error. Be found discussions with Hike 
Fischer helpful in analyzing schemata with resets. 
The Beset Theorem: 

The class of reset push down scheaa autoaata is eguivalent to the 
class of ordinary push down schema autoaata. 

He shall show how we can translate a reset push down scheaa 
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into an equivalent ordinary push down schema. An ordinary function 
call (f x//1 ... x//n) will be translated into {call (f x//1 .-• x//n) 
(y y// 1 ••• y// 1 > body) where we will explain the body below. The 
idea is that if the function f wants to execute a non local transfer 
of control through argument x//i we can simulate this by returning the 
corresponding y//i as "exit" or "again" depending on whether the block 
x//i is to be exited or reiterated respectivey. Then the procedure 
which makes the call tc f can test the values of the y//i and take the 
appropriate action depending how the name was generated. Consider the 
following example: 



{try x) = {repeat t1 {) 
(if (Q x) 
then 

(X <- (F X)) 
else if (P x) 
then 

{x <- {harder |F x) tl)) 

;"the name tl is an identifier" 

{if (not x) 

then (return false) ) 
else (return false) ) ) 

(harder x1 tag) * (repeat () 
(if (Q x1) 
then 

(x <- (F x1)) ;"set the global x to (F x1) H 
(again tag) ; "reiterate the repeat loop named tag" 
else if (P x) 
then 

(x1 <- (harder (F x1) tag)) 
(if (not x1) 

then (return false)) 
else (return false) ) 

we can rewrite try and harder as try" and harder 1 respectively so 

that resets are eliminated. 
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{try* x) = (repeat t1 {) 
{if (Q x) 
then 

(x <- (P x))) 
elseif (P x) 

t eD (x <- (call (harder* (f x) t1) (y yl y2) 
(if 

(is y2 "again") 

then 

(again t1) 

elseif 

(is y2 "exit") 

then 

(exit t1) 
else y))) 
(if (net x) 

then (return false) ) 
else (return false))) 

(harder* x1 tag) « (repeat () 
(if (Q xl) 
then 

(x <- (F xl)) 

(exit harder 1 false false "again") 

;"reiterate the loop named tag" 

elseif (P x1) 
then 

{x1 <- (call 

(harder (F x1) tag) 

(y yi y2) 

(if 

(is y2 "exit") 

then 

(exit harder* false false 



"exit") 



"again") 



elseif 

(is y2 "again") 

then 

(exit harder* false false 

else y) ) ) 



(if (cot x1) 

then (return false)) 
else (return false)}) 
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r^> 8.1.1.1.4 Decompilation 

The Decompilation Theorem: 

For every pash down schema automaton we can effectively construct a 

side-effect equivalent recursive schema. 

Proof: 

The only difficult constructs to translate are the push and 
pop commands. He shall translate (push <value» as «function> 
<value> tags false) where <functi.on> is a unique function name 
distinct from all others. The function is defined to be have two 
arguments x and y and have a body which is the code that fellows the 
^ push command which is teing translated. The command (pop) is 

translated as (GO <tag» <tag>: where <tag> is a unique tag distinct 

from all others, whereas (pop <identifier>) is translated as 
«identifier> •<- x) (Go <tag» <tag>:. The idea is that there must 

be a tag for every instance of a call to pop so that control can get 

back to the proper place. 

Consider the following push down schema automaton: 

(f y) = (block () 
(push) 
(call 1 g) 
(return 1) ) 

(9 y) * (repeat () 
(push) M 

(call 1 p) 

(iftrue 

(pop) 

(push) 

(call 1 Q) 



Th 
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(iftrue 

(POP) 

(repeat () 

(ifempty 

(teraxnate "t") ) 

(pop))) 
else 

(pop) 
(pop) 
(ifempty 

(terminate false)) 

else 

(call 1 B) 

else 

(pop) 
(push) 
(call 11))) 

e scheaa f can be decompiled as follows: 



(f x) = (block °uter^ aise £alse £alse false «t«) > 

ifO x n1 n2 n3 nU o5 n6 empty) = (repeat () 
t iu xi«« it1 t2 t3 ta £ 5 ^6 false) 

(x <- <P x)) 

(if 

x 

then 

(go a1) 

tl: 

(f2 x t1 t2 t3 t4 t5 t6 false) 

(x <- (Q x)) 

(if 

x 

then 

(go &2) 
t2: 

(repeat () 

(if 

empty 

then 

(exit outer *t") ) 

(go n3) 
t3: 
) 
else 

(go nH) 
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tU: 

(go o5) 
t5: 

(if 

eapty 
then 

(exit outer false) 
else 

(x <- (H x)))) 
else 

(go n6)) 
t6: 

(f3 x t1 t2 t3 tU t5 t6 false) 
(x <- (L x))) 

(f 1 x nl n2 n3 n<l n5 n6 eapty) » (block () 

x 
then 

(go nl) 
else 

(go n2))) 

(f2 x n1 n2 n3 nH n5 n6 eapty) * (block I) 
/""*\ ( if 

x 
then 

(go n3) 
else 

(go nil))) 

(£3 x b1 n2 a3 nl o5 »6 eapty) « (block () 

(£0 x nl n2 n3 n4 n5 n6 eapty)) 
8.1.1.1.5 Pciaitive Recursive Scheaata 

Definition a recursive scheaa f will be said to be PRIHITIVB 
RECURSIVE in tne the uninterpreted function syabols if f can be 
defined recursively as (f x//1 ... x//n) * phi[x//1 . # . x//n ] where 
each instance (f t//1 ... t//n) of a call to f within phi[x//1 ... 
x//n] has t//1 of the fora (h x//1) where h is in the set and the 
^ only other functions in the definition are either uninterpreted or are 
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themselves primitive recursive in 0. 

For example the following schema is primitive recursive in {L 

B}. 

{f x) = if (P x) 

then (Q x) 

else (C (f (I x)) (f (B x))) 

The following schema is not primitve recursive in \S) : 

(acKer.an.. ,^ } . 

then 

if (Z «) 

then y 

elseif (0 w) 

then (ZERO) 

else (ONE) 

elseif (Z w) 

then 

(P 

(ackerman (ZEBG) (S x 1) y) 

(OME)) 

else 

{ackerman 

<S w 1) 

(ackerman w (S x 1) y) 

y)) 
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8.1.1.2 Schemata with Counters 



He would like to present another example of a function that 
can be computed by a recursive schema but not by any program schema. 
Define (F-n x) as in the proof of the Single Instance Theorem. Thus 
((F-*n*1) x) = (f (F-.n x)). Suppose that we successively compute (F 
x), (F (F x)), etc. As we successively compute the quantity (F-i x) 
for some integer i we shall keep a running count of the number of 
times that (P jF-j x)) has been true for j less than i, minus the 
number of times that (P (F^j x)) has been false for j less than i. if 
this count ever goes negative then we shall return false as the value 
of the function (zerc x) , otherwise the function (zero x) will run 
forever. 

The Counting Conjecture for Program Schemata 

The recursive schema 'zero' defined below is not schematically 

equivalent to any program schema. 

(zero x) = (repeat a () 

(if (P x) 
then 

(x <- (positive (F x) ) ) 
(if x 

then 

(again a) ) 
else 

(return false) 
else 

(return false) ) 

end 

^ The schema «zero» uses the schema 'positive* to keep track of the 
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count by the depth of recursion of th€ schema f positive*. 



(positive x) * (repeat a () 

(it (P x) 
then 

(x <- (positive (F x) ) } 
(if x 

then 

(again a) ) 
else 

(return false) 

else 

{return (F x) ) ) 

end 

Using the technique of loop elimination »e can convert the above 
functions into purely recursive scheiata. He shall define a schema 
zerol nhich is equivalent to zero and a schema positive 1 which is 
equivalent to positive. 

(zerd x)« (if (P x) 
then 

(if (posit ivel (F x) ) ) 
then 

(zerol (positive 1 (F x))) 
else 

false) 
else 

false) 

(positivel x) = 

(if (P *) 
then 

(if (pcsitivel (F x) ) 
then 

(positivel (positivel (F x)J) 

else 

false) 
else 

(F *)) 
The protocol tree for the schema zero is 
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(if (P (F-0 x)) 
then 

(it (P (F-.1 x)) 
then 

(if (P (F-»2 x)) 
then 

• * • 

else 

(if {P (F-3 x)) 
then 

• • • 
else 

(if {P (f-4 x)) 
then 

... 

else 

false) ) ) 
else 

(if (P (P-.2 x)) 
then 

(if (P (F^3 x)) 
then 
else 

(if (P (F-»4 x)) 
(•""N then 

else 
else 

false)) 
else 

false) 

However a progra» schena can solve the problei if we give it a 

counter. He postulate the functions "♦", "-«, and zero? which 

respectively add, subtract, and test for zero. The following prograi 

scheaa is schematically eguivalent the the function zero: 

(zerol x) * (block (n) (return (zero 2 x) ) ) 
(zero2 x) « (repeat () 

(if (P x) 
then 

(x <- (F x)) 
(n <- n ♦ 1) 
else 

(if (zero? n) then (return false)) 
(n <- n-1))) 
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By allowing recursive schemata to use a counter, we can construct a 
function 'reczero* that is not equivalent to any ordinary recursive 
schema, the function reczero counts the number of nodes along the 
bottom of the L-R tree that have the property P minus the ones that do 
not have the property P. The function returns the value false if the 
count ever goes negative. Be assume that arguments are evaluated from 
left to right. 

The Counting Conjecture. for Recursive Schemata: 

The schema (with counters) reczero defined below is not equivalent to 
any ordinary recursive schema. 

(reczero x) - (block (n) (return (reczerol x) ) ) 

(rec zero 1x) = 

K (if (BOTTOH? x) 

then 

(if (P x) 
then 

(n <- n+1) 
true 
else 

(if (zero? n) then (return false)) 

(n <- n-1) 
true) 

€sXS6 

(if (net (reczerol (1 x) ) ) then (return false)) 
(if (not (reczerol (R x))) then (return false)) 
(return true) ) 

The reason that reczero is not equivalent to any recursive schema is 
very similar to the reason that no recursive schema can search the 
branches of the L-B tree in parallel. If a recursive schema is 



r^ 
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equivalent to reczero then it is constrained to search the tree in 
essentially the same order that reczero searches the tree, otherwise 
it could be made to fall into an infinite loop on an interpretation 
where reczero converges. Be conjecture that constrained in this 
fashion a recursive schema has only a finite number of states in which 
to try to keep the count. The recursive schema cannot succeed for. the 
same reason that we conjecture that no program schema is equivalent to 
the function zero defined above. 

Conjecture: the following function is not 
schematically equivalent to any purely schematic recursive system of 
equations. Tte function even is supposed to test whether the number 
of bottom nodes of a L-B tree that are true for the predicate P is the 
same as the number that are false for the predicate P. The schema 
•even* differs from the schema 'reczero* in the crucial respect that 
•even* always looks at all the bottom nodes before it ccmes to any 
conclusions. Thus a recursive schema that tries to imitate the 
schema even has a lot more room in which to maneuver. He conjecture 
that no recursive scheia can have enough internal states to be 
equivalent to the function even defined below. 



(even x) = (block (n) 
(evenl x) 

(return (zero? n ) )) 

(evenl x) = 

(if (BOTTCH? x) 
then 

(if (P x) 
then 

(n <- n*1) 
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x) 
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>lse 
(n <- 

x) 


else 
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(L x>) 




(even 


(R x))) 



<- n-1) 



/"""N 



8.1. 1.3 page 365 
8.1.1.3 Parallel Scheaata 



Be introduce the delimiters "| (" and «) « to delimit quantities 
that are to be conputed in parallel. Whenever a process executes an 
expression like | (x) it divides into two processes, one process 
executes x and the other attempts to continue nornal execution. For 
exaaple in the expression | (2+3) * (4*5) , the product <**5 is coaputed in 
parallel with the sua 2*3. Thus the expression "(block {{return x) 
(return y) ) " is defined to be the value of x or y depending on which 
evaluates first in scae particular but unspecified parallel 
computation. Processes can coordinate their actions through locks. 
/"*"> Any expression x can be locked by (lock x) provided that the 

expression is not already locked. If x is already locked then any 
process which executes (lock x) will be blocked until x is unlocked by 
the priaitive (unlock x) . However a process can execute (locked? x) 
which will return true is x is locked but will lock x if it is 
unlocked. The kind of call deliaited by "| (•» and ") " can be 
iapleaented using the following primitives: 

(create f) will create a new processwhich will begin execution 
with a call to f and will return the naae of the created process as 
the value of the function create. 

(resuae (p send-args) f) will suspend execution of the process 
that calls resuae and will resuae execution of the process naaed p 
with arguments send-args. If the process p is already running then 
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the process which called resuume will fce blocked antil p becomes 
suspended. If the process which called resume is itself ever resumed 
then it will invoke f with the arguments recei/ed. 

(fork (p send-args)) will resume exeuction of the process p 
with arguments send-args and in parallel return the name of the 
process forked as the value of the function fork. 

(interrupt p x) will interrupt the execution of the process p 
and then begin execution of x IN THE PfiCCESS p. 

(step p) will step the process p through one step. 

By adding the above primitives we obtain the class of Parallel 
Schemata. It is our thesis that the class of Parallel Schemata is in 
fact UNI VESs AL for the class of all effective schemata. By this we 
mean that for any effective schema there is a timing side-effect 
eguivalent parallel schema. Two automat a and b will be said to be 
timing side-effect equivalent if for every computation of a there is a 
side-effect equivalent computation of b where the timings of the 
control primitives of b are allowed to be arbitrarily adjusted and 
vice- versa. 

He define the following function using parallel processing: 

(f x)=(if (P x) 

then x 
else 

begin 



end) 



| (return (f (L x))) 
(return (f (B x) ) ) 
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The above function is determinate {i.e. halts and has the same value 
independent of the relative speed at which the sub-processes run} on 
infinite binary trees in which the predicate P is true en only cne 
node. 

The Parallel Evaluation Theorem: 

The function f defined is net equivalent to any recursive schema. 
Proof: Suppose a set of recursive eguations {f//0, f//1, ..., f// n } 
is schematically equivalent to f with f//0 equivalent to f. That is 
for all interpretations of the uninterpreted function symbols, the 
schemata f and f//0 are the same function. Suppose that we start up 
f//0 on input x and make the predicate F false for every node to which 
it is applied as f//0 computes along, if the computation converges 
^ then f//0 does not leck at seme node which is a contradiction of the 
supposition that f//0 is eguivalant to f. Therefore the computation 
runs forever and the sequence of statements through which the control 
passes is ultimately periodic, consider the sequence of arguments to 
one of the functions (call it f//i for «f subscripted by i") as the 
control passes through one cycle. Suppose that f//i is a function of 
j arguments: a//1,.. .,a//j. The arguments with which f//i will be 
called after the control has passed through one cycle are terms 
definable from a//l, .. .,a//;j. Let us call them a//1-»1 # ..., a //j-1. 
The situation can be diagram led as follows: 



(f//i a//1,. .•,a//j) ; the beginning of the cycle in the 
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control structure 

(f//i a//1-«1, ...,a//j-1) ; Be pass throuqh the sane point of 
the cycle in the contxcl structure 

If none of a//1-1, . ,. ,.a//j-.1) is the sane as one of a//1,....a//1 

then we are done since the arguments of the recursive equations are 

tracing j paths down an expontentially growing tree which means that 

some node is not looked at. If we set the interpretation so that P is 

true for the node then we have a contradiction. He conclude that the 

fact that one of a//1-.1, ...,a//j-.1 might be same as one of 

a//1,...,a//j is a nuisance. Let us call the arguments to f//i after 

we have gone through the cycle k times a//1-»k,...a//j-k. Observe that 

if we go through the cycle jl times then there will be some i such 

that i is less than j! and a//1-i,.. .,a//j-i has the property that it 

is an epicycle. By this we mean that some a//g-*i is the same as one 

of a//1, ...,a//j if and only if it is the same as a//g. All such a//g 

do net contribute to the number of nodes examined since they are 

repeats of nodes previously examined in exactly the same way. The 

situation can be diagrammed as follows: 



(f//i a//1,...,a//j) ; 
(f//i a//1-»1, .«*.a//j-.1) 
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the contiol'structu're '—* / 'W. th« beginning of the epicycle in 

« 

point in l \(i^illcir k) ■"*-< 2 **n; «• P«» through the sa.e 

Threrefore we can coaplete our proof by applying tc epicycles the 
above argument that we used for cycles. 



8.1.1.4 page 370 
8.1.1.4 Locative Scbeuata 

The Locative Tfceorem: 

If locations of identifiers are an allowed data type, then the control 

structure of recursive schemata can compute any partial recursive 

function. 

Proof: 

Let (at x) denote the location of the identifier x. 
Furthermore suppose that we have a function in of cne argument which 
will return the contents of its argument. The proof will be phrased 
in terms of pushdown schema machines. We can define a counter using a 
register as fellows: 

{block {(cl false)) 

(initialize-ccunterl) * (block ((w false)) 

(push (at w)> 

(pop d)) 
(count-up1) * (block ( (y false)) 

(push d) 

(pop y) 

(push (at y)) 

(pop d)) 
(count-downl) = (block () 

(push d) 

(call 1 in) 

(pop d)) 
(zero-tes€l) * (block () 

(push d) 

(call 1 in) 

(iftrue (push "t") ) else (push false)))) 
Harvin Minsky proved that two counters are universal. Q.E.D. 
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8.1.1.5 Schemata with Selectors and Replacement 

Another way in which we can proceed is to impose data types on 
the computing domain, storage off the stack can be established by 
postulating a constructor c and selectors s1 and s2 such that for all 
x and y in the computing dcmain we ha*e: 

(si (c i y)) = x 

(s2 (c x y)) » y 
in the domain of interpretation. Classically we would postulate that 
every call to the constructor must return a new element of the 
computing domain. 



r^ 
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8.1.1.6 Schemata with Free Variables 



(c x y) = (block (z) , • «.»» 

(2 <- (si f ree-storage-list) ) 
(free-storage- list <- (s2 f ree-storage-lrst) ) 
; "free-storage-list is free in c" 
(return (CONSTRUCTOR x y 2) ) 

The point is that in general (c x y) will not be the same as (c x y) 
because of use of assignment on the free varialbe free-storage-list. 
Other than in this fairly trivial way, schemata do not add any power 
to recursive schemata. 
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8.1.1.7 Schemata with Equality 



Schemata with equality are allowed to make use of a special 
predicate (= x y) whose interpretation is that x and y are the same 
element of the domain cf interpretation. Universal donains of 
interpretation for schemata with equality are the Herbrand universe 
with a congruence relation theta such that: 

1: theta is an equivalence relation 

2 i i £ x/1 £ het 5 y/ 1 « •«•» and x /n theta y/n then for each 
uninterpreted function f and predicate p: 

(f x/1... x/n) theta (f y/1 ... y/ D ) and 

(p x/1 ... x/n) if an only if (p y/1 ... y/n ) 

^ In other words the elements of the doaain of interpretation are the 
equivalence classes of theta. 
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8.1.1.8 Hierarchical Backtrack Schemata 



PLAHHEB uses a more powerful control structure than that of 
the recursive function call. A BACKTRACK CONTROL STRUCTURE is used 
which aeans that at any point a process can fail which will cause it 
to back up to some previous state and then continue. The primitive 
function (FAIL) will generate a simple failure. The primitive 
function (FAILPOIHT try lose) will evaluate the expression try. If 
the evaluation succeeds then the value of the function FAILPOIHT is 
the value of try. Otherwise the value of the function FAILPOIHT is 
the value of lose. For example the value of 

<♦ 

(failpcint (x <- 2) (x <- 3)) 

(if x=2 then (fail) else 4)) 

is 7 since x first gets the value 2 but then is given the value 3 when 

a failure backs up tc the function FAILPOIHT. 

8.1.1.8.1 Comparison with Recursive Schemata 

He shall give an example tc show that backtrack control 
structure is more powerful than recursive control structure. 

Backtrack Schemata Are Hore Powerful than Recursive Schemata 
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The backtrack schema g defined below is net equivalent to any 
recursive schema, what the schema g does is to search the following 
tree for x looking for a node on which P is true: 



(1-1 x) 

(1^2 x) 

(L-3 x) 

(R-1 CI-2 x)) 

(IN1 (L-.4 x)) 
(B-1 (L-1 x)) 

(B-2 (L-0 x))) 
(R-1 X) 

(B-.2 x) 

(B-3 x) 

He have shown in the section on parallel schemata that no recursive 
_^ schema can do the search. 

(9 «> » <h (f x)) 

(h z) = (if z 

tfcen 

"true" 
else 

(fail) ) 

(f x) = 

(fail? 

(P x) 
(block (y) 

;"y is a new local" 

(Y <- *) 

(k 

(f (L *)) 

(if (P y) 

then true 

else (y <- <R y) false))))) 



f"\ 



The reason that we make the function k defined below into a seDar*** 
function xs so that BOTH arguments will be evaluated. separate 
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<k s t) = if s 

then 

"true" 
else t 

Proof: The procf is similar to the proof of the parallel 
evaluation theorem. Suppose a set of recursive equations {f//0, f//1, 

f//n} is schematicaly equivalent to f with f//0 equivalent to f. 
Suppose that we start up r//0 en input x and make the prdicate p true 
for every node to which it is applied as f//0 computes along. If the 
computation convereges then f//0 does net lock at some node which is a 
contradiction cf the supposition that f//0 is equivalent to f. 
Therefore the computation runs forever ana the sequence of statements 
therough which the control passes is ultimately periodic. 

8.1.1.8.2 Comparison with Multiprocess Schemata 

The method by which multiprocess schemata can simulate 
hierachical backtrack schemata is messy but straight forward. 

Hultiprocess schemata are more powerful than backtrack 
schemata. One example which may show this is the one used to show 
that parallel schemata are more powerful than recursive schemata. 
Unfortunately we have not yet been able to prove that backtrack 
schemata cannot search the full L-B tree. So we shall resort to brute 

force techniques. 

We would like to define the p-length of an expression x as the 
number of times which D can be applied to x before (P x) is true. 
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Thus (P-length x) *■ (if (P x) then else U (P-length (D x) ) ) Now we 
would like to define a schema expt such that 

(expt x y) * (I^{2-^ (P-length x)) y) 
Suppose that (P-length x) * 2. Then (expt x y) « (I-« (2-*2) y) = (1^4 
y) - (I (I (I (I y)))). 

(expt x y) * (if (P x) 

then 

(I y) 
else 

(expt (D x) y (expt (D x) y) ) ) 

Now we claim that there is no program scheta which is 
equivalent to expt. Suppose to the contrary that there is a program 
schema with k registers and s statements which is equivalent to expt. 
Such a program schema has at most only s * k- (P-length x) equivalence 
classes of states. Thus if it runs for more than s * k- (P-length x) 
steps it must be in a loop. Therefore it cannot possibly produce the 
output (I-* (2-* (P-length x) ) y) since s * k-(P-length x) is less than 
2-* (P-length x) for large values of (P-length x) . This is a 
contradiction. 

In an exactly analogous fashion we can prove that there is no 
recursive schema expt2 such that 

(expt2 x y) = (I- (2^ (2-* (P-length x) ) ) y) 
Suppose that there is a recursive schema with k registers and s 
statements which is equivalent to expt2. Such a recursive schema has 
at most only 



/**\ 



RECURSIVE SCHEMATA 



STACK OF REGISTERS 



k REGISTERS 



n nrzn 



I I 

I I 
I I 



/"""N 



EACH REGISTER CAN HOLD AN 
INTEGER UP TO n. 




HAS AT MOST sn k n 8nk STATES 



s STATEMENTS 



8.1. 1.8 page 378 

J = s * (P-length x) -ik * (P-length x)-»(s * (P-length x) -k) 
eguivalence classes cf states. The same state counting argument shows 
the contradiction. The above argument has been independently 
discovered by Hobin Kilner. 

Theorem: Multiprocess schemata are more powerful than backtrack 
schemata 

Proof: Me will apply cur brute force technique. There is no 
backtrack schema expt3 such that 

(expt3 x y) = (I- (2- (2- (2- (P-length x) ) ) ) y) 
Suppose that there is a backtrack schema with k registers and s 
statements which is equivalent to expt3. Let J be as defined above. 
The recursive schema has at most J-J equivalence classes of states. 
Thus if it runs for more than J-«J steps it must be in a loop. 
Therefore it cannot possibly produce tfce output {!-. (2^2-.2-^ {P-length 
x)) y) since J-J is less than 2-2-2^ (P-length x) for large values of 
(P-length x) . This is a contradiction. 
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8.2. Synthetic Theory 



8.2.1 Realizations 

8.2.1.1 Realizations for the Quantificational Calculus 

lie would like to she* how we can use schemata to express 
procedurally the meaning of certain constructive logically valid 
sentences in the predicate calculus, classically, intuitionistic 
logic has been U3ed to prove constructive sentences. However, the 
connection between this language and push down schema automata is 
somewhat indirect, «e need to define the notion of a schema g 
realizing a formula phi. Roughly speaking g realizes phi if it tells 
how to compute the value of phi from the subformulas of phi depending 
on the logical connectives of phi. Kleenex notion of M g realizes 
phi" is defined by inducticn en the structure of phi: 

For {terms) . g realizes phi where phi is a term if g is true 
if and only if phi is true. For example (P (F w) z) realizes (P (F w) 

z). 

For {and...}, g realizes phi = (and theta Fsi) if (g 0) 
realizes theta and (g 1) realizes psi. Bote that g really is two 
functions in disguise. 

For {or...}, g realizes phi ■ (or theta psi) if whenever (g 0) 
is false then (g 1) realizes psi and whenever (g 0) is not false then 
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(g 1) realizes theta. 

For {iiplies...}. g realizes phi = (implies theta psi) if 
«henever h realizes theta then (g h) realizes psi. 

For {not.,.}, g realizes phi = (not theta) if for no h is it 
the case that (g h) realizes theta. 

For {all...}, g realizes phi = (all x [theta x]) if for all x 
it is the case that (g x) realizes [theta x]. 

For (some...}, g realizes phi = (soae x [theta x ]) if (g 1) 
realizes [theta (g 0) J. 

Consider the following formula which we shall call phi: 

(implies 
f^ (some x 

(implies (A x) (B x) ) ) 
(implies (all x (Ax)) (some x (B x) ) ) ) 

Be claim the function g defined below realizes phi. 

g * (lambda h (lambda k (lambda s 
(if s = 

tlen (h 0) 

else ((h 1) (k (h 0))))))) 

Suppose that fa realizes (some x (implies (A xl in *\\\ 
(h \) realizes (implies |a (h 0} } (I (h 0)7) ( }>) 

suppose that k realizes (all x (Ax)) 

(k (h C)) realizes (A (h 0)) 

<0» 1) (k (h 0))) realizes (B (h 0)) 

<<<g h) k) 1) realizes (B ( { (g h) k) 0)) 

((9 h) k) realizes (some x (B x) ) 

g realist pL"" 11 "* <UplieS ( * U " ( » x " < so "« * « 8 *» » 



/~\ 



8.2. 1 page 381 

He are interested in knowing when a formula can be realized 
constructively. 

Realization Theorem for Recursive Schemata with Functional Arguments. 

If phi is prcveable in intuitionistic logic, then phi is 
realizable by a recursive schema with functional arguments. The 
Realization Theorem represents one approach toward a constructive 
theory of computation. From a description of the kind of object that 
we would like to have given the description of certain other objects 
as input, we derive a program for computing our goal. Actually we 
shall prove that for intuitionistic logic the realization function can 
be made primitive recursive. The proof is a slight modification of 
the standard proof for the integers. It is a warm up for the 
analogous proof for the deductive system of PLANNEE. However, in 
PLANKEB we require the full power of the recursive functions for our 
constructive realizations. 

Proof: The following proof is by induction on the structure of 
intuitionistic proofs using natural deduction. It goes by 
straightforwardly winding and unwinding of definitions. With a little 
work we could get PLANNER to create the proof. 



{and introduction! 

1 theta realized by say g 

psi realized by say h 

^and theta psi) realized by (lambda s (if (s = 0) then g else 
h>) 
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{and eliminaticD} 

(and theta psi) realized by say g 

theta realized by (g 0) 
psi realized by {g 1) 

{or intro} 

psi realized by say g 

^ (or theta psi) realized by (laabda t (if t«0 then false else 
^ (or psi theta) realized by (lambda t {if t «0 then true else 

{or eliia} 

(or theta psi) realized by say g 

theta hypothesis; suppose that theta is realized by h 

eventually deduce say cmega which is realized hv (m m 
for some recursive m using the inductive hypothesis reail2ed by (m h) 
,-s psi hypothesis; suppose the psi is realized by k 

eventually deduce omega which is realized bv (1 k\ f nr 
some recursive^ «sing the inductive hypothesis ceaxiZea by {1 k) for 

^ omega which is realized by (if (g ) then (o (g 1, ) e i se a (g 

{implies intro} 

omega hypothesis; suppose omega is realized by h 

f rt - ™« eventually deduce say psi which is realized by ta hi 
for sooe _fecursive 9 using the inductive hypothesis. Y (9 ' 

(implies omega psi) realized by (lambda h (g h) ) 

{implies elim} 

(implies omega psi) realized by say g 
omega realized by say h 

psi realised by (g h) 
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[neg intro} ^^ hypothesis; suppose that omega is realized by fa 

eventually deduce say {not psi) which is realized by 
(g h) for some recursive g using the inductive hypothesis 
w ' eventually deduce psi *hich is realized by (k h) tor 

some recursive k using the inductive hypothesis. 

7not"oiiiega) which is realized by any function since it is 
impossible for both (net psi) to be realized by (g h) and for psi to 
be realized by (X h) . 



{all intro} 



I 
1 



| eventually deduce say [omega x] which is realized by 
(g x) for soae recursive g using the inductive hypothesis 

{all x [omega x]) realized by (lambda x (g x) ) 

{all e 1 "^ x [OBega x]) realized by say g 

[omega t] for some term t; realized by (g t) 
(exist intro}^ ^ ^ realized by ^y g Mhe]:e t is a term 

1e^ist"x"[ omega x]) is realized by (lambda s (if (s = 0) then 
t else g)) 

{exist elim]( e ^ [omega x]) rea lized by say g 

x| [omega x] realized by (g 1) 

I 
I 



i eventually deduce say psy which does not contain x 
free; psy is realized by (m (g 0) (g 1)> for some recursive m using 
the inductive hypothesis. 
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psy 
Thus we have ccnpleted the inductive proof. 

Intuitionistic Implementation Theorem 

For every recursive schema P, we can effectively find a first 
order formula [theta x y] such that P is total if and only if (all x 
(some y [theta x y ]) ) is proveable in intuitionistic logic. 
Furthermore, the program P on input x converges to the value y if and 
only if f theta x y ] is proveable in intuitionistic logic. He assume 
that all uninterpreted function symbols in schemata are total. 

We shall give an example of how to construct the formula theta 
r^ for the following program which is due to Paterson: 

(g x) = (if (T <f x i) 

tben <h x (F x) ) 
else x) 

(h x y)= ^ 

(if (T (F (F y))) 

then x 
elseif (1 (F x)) 

then (h (F x) <F (F y))) 
else (g (F x) ) ) 

M can obtain the formula that we require by doing a straight forward 
translation of the recursive equations into the guantif icational 
calculus. These formulas are similar in intent to those of Hanna, 
however we need use only intuitionistic logic to obtain the result we 
require. The formula £ theta x y] to be constructed is the 
f^ conjunction of the following three formulas where -iff" is an 
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abbreviation for "if and only if**: 



(iff 

(PG x y) 

(or 

(and (1 (F x)} (PH x (F x) y) ) 
(and (not (T (F x) ) (y = x) ) ) ) ) 

iff 



(all x1 x2 y (iff 

(PH xl x2 y) 

(or 

(and (1 (F (F x2) ) ) (y = x1)) 

(and 



(and 



(not (T (F (F x2)))) 

(T (F x1)) 

(PH (F xl) (F (F x2)) y)) 

(not (1 (F (F x2)))) 
(not (T (F x1})) 
(PG (F x1) y))))) 



(all x (or (T x) (not (T x)))) 

The last statement cones from the fact that we are assuming that all 

uninterpreted functions are total. The schema g is indeed total. 

Even after adding selectors and constructors the realization 
theorem can still be proved in the standard way. He introduce the 
predicate atom which tests to see if its argument is atomic and thus 
cannot be broken down using the selectors. The following rule is 
added to intuitionistic logic: 

(all x (implies (atom x) £ theta x])) realized by say g 
x,y|[ theta x] hypothesis; suppose [theta x] is 

realized by (m x) , . , . , . . 

| [theta y] hypothesis; [theta y] is realized by (m 

y) 

l 
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,u . • ] eventually deduce [ theta (c x 7)1 realizes hv «* 

(h ■ x y) using the inductive hypothesis realized by say 

(all x [fcbeta x]) realized by 
(k x) = {if (atom x) 

then (g x) 

else (h k (s1 z) ( S 2 z) ) ) 

Sometimes an increase in efficiency can be obtained from 
replacement operators i1 and r2 such that 

z) - w, anY(sVz> 1 J,"* 7 = (S2 2) then after < rl z «> «• *«• d 
2) - x, laVjs^ 1 ;, 1 ^w! " Y = {S2 2) th6n after < r2 z *> we ha ** d 

We shall call schemata that allow the use of selectors and replacement 
operators list structure schemata. Two schemata will said to be 
equivalent as list structure schemata if for all interpretations of 
the uninterpreted function symbols they are the same function. For 
schemata that dc not explicitly contain s1, s2, r1, or r2 list 
structure equivalence is the same as side-effect equivalence. He have 
shown above how to construct a universe of terms so that two schemata 
are side-effect equivalent iff they are equivalent over the domain of 
terms. it is impossible to use the universe of terms as a universal 
domain of interpretation when the use of replacement operators is 
allowed. 
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8.3. Current Problems and Future Work 



How can we characterize more precisely the difference between 
functions that need to use a recursive or parallel control structure 
as opposed to those that only need a simple iterative proqram 
structure? The problem of deciding whether any given recursive 
schema can be rewritten as a program schema is of course undecidaole. 
We would like to find general criteria of independent interest which 
would be sufficient to guarantee that a recursive schema could not be 
rewritten as a program schema. 

There is general agreement that the theory of computation is 
currently not in good shape. The three major areas (automata theory, 
recursive function theory, and special case hacks) are not applicable 
to practical programs. He can contrast our plight with the situation 
in applied physics. An applied physicist finds that it is essential 
to understand fundamental physical laws both in designing his 
experiments and in interpreting their results. No such fundamental 
laws and principles are kncwn in programming. Recursive function 
theory sets the very outer limits of what is possible. Few theories 
are more elegant. However, the fact that classical recursive function 
theory deals with the indices of the partial recursive functions and 
not with the meaning of the programs has been a fundamental 
limitiation on the applicability of the theory. Tor example the 
recursion theorem says that fixed points exist for any acceptable 
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Goedel numbering. Alacst all the classical theoreas of recursive 
function theory can be derived using only the Godel axicas for indices 
of partial recursive functions, similarly, the coaplexity theory of 
the recursive functions can be derived froa Blua's axicis for indices. 
Autoaata theorists have been able to discover soae of the structure of 
various liaited classes of autoaata such as finite state aachines, 
push down machines, and space and tiae bounded aachines. However, 
since the theory developed has been aostly concerned with closure and 
complexity properties of the special aachines considered as acceptors, 
it has had liaited applicability to real coaputer prograas. Host 
prograas are not structured in the way reguired to fall into one of 
the special classes of aachines. Soae theorists hope that by studying 
/■s, enough exaaples of very narrow doaains of algorithas where we have a 
lot of doaain dependent knowledge that we can induct a theory of 
coaputation in a Baconian fashion. Deep studies have been Bade on 
questions such as how fast integers can be aultiplied and how fast 
aatrices can be aultiplied. studies in the theory of searching and 
sorting appear to be acre relevant for constructing a unified theory 
of coaputation since they are concerned with basic computational 
abilities. 

Studying the properties of prograas schematically offers 
several advantages. Schemata can be prograaaed in a realistic 
fashion. They airrcr the structure of programs that are used in 
applications. using them we can precisely define structural 
properties. Properties of the structural classes can be 
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aenonstratea. Schemata give us a tool by which we can rigorously 
formulate ana prove statements that every programmer intuitively 
knows. He have usea schemata to make a kina of aistinction between 
semantic ana syntactic extensions to programming languages. The 
intent of the restriction that functions be uninterpretea is to try to 
prevent our mathematics frcm falling into what Perlis likes to call 
the "Turing Hachine Tar Pit." By using uninterpretea function symbols 
we can prove both analytic ana constructive theorems about classes of 
programs. In the analytic theory the mathematical properties of the 
structural classes is expounaea. In the constructive theory the 
process by which schemata can be constructea from goal orientea 
language such as PLIMNE8. The intention is only partially realizea 
ana we must search for ether natural mathematical structures to impose 
on our schemata in oraer to obtain a more realistic theory of semantic 
extensions to programming languages. He are continuing to investigate 
what gains in efficiency can be obtainea from the following extensions 
to programming languages: 

recursion 

fcacktrac* control structure 

PIftNHEE primitives 

Locations as a type 

resets 

free iaentifiers 

parallel evaluation 

replacement operators for constructors. 
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identity test as a primitive 
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tabs are 8 spaces 
!»*$%&* <) 
*+,-./0123 
456789: ;<= 
>?3ABCDEFG 
HIJKLUNOPQ 
BSTCVWXYZf 
t }-«_*abcde 
fghijklnno 
pqrstuvwxy 
z{l}° 
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10. Index of Procedures 



The type hierarchy is given at the beginning of chapter 4. 
The syntax primitives are given after the function BEAD. The page 
number gives the explanation of the procedure. 
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Index of Procedures 
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150 
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187 
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149 
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13U 

■> 

180 
7 

180 
1<*9 
179 
79 
99 
77 
111 
178 
15U 
191 
192 
93 
92 
210 
133 
171 
191 
1<I8 
215 
214 
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133 
167 



ABS 

ACTIVE 

ACTOR 

ACTOB-CAI1ER 
ACTOB-FUNCTION 
AGAIN 
ALL 

ALPHABETIC 
ALTEBI-PEBSISTENT 
/~\ ALTEBI-TENTATIVE 
AND 

AND? 

ANTECEDENT 

ABC 

ABGS 

AS 

ASCENDING? 

ASSEBTI-PEBSISTBNT 

ASSEBTI-TENTATIVE 

ASSIGNED? 

AT 

ATC 



ATOM '.-CONSTRUCTOR 
ATOMI-DECCMPCSEB 

BE 

BINDINGS 

BITS 

BLOCK 

BLOCKBIND 

BOTTOH 

BOUND? 

BYTE 

CALL 

CALL 

CALL 

CALL 

CANDIDATES 

CATCH 

CHANNEL 

CHARACTER 

CHARACTER- VECTOR 

CHOPJ-PERSISTENT 

CHOPI-TENTATIVE 

CLAUSE 

CLAUSE 

CLAUSE-OF 

CLOSE 
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146 

186 

178 

171 

146 

157 

109 

140 

172 

146 

111 

99 

120 

101 

213 

94 

154 

154 
86 

139 

139 

239 

238 

239 

154 



CLOSURE 

COND 

CONSEQUENT 

CONTAINS 
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COPY 

CURRENT 

CURRENT? 

DAGGER 

DEBUG 
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DEC! -TENTATIVE 
/"^Y DECLA RATION 

DECLARE 

DECLARED 

DELETE-PRO NT 

DELETE-REAR 

DESCENDING? 

DIGIT 

EDIT 

EITHER 

ELEMENT 

EHPTY 

ENPTI? 

END- BLOCK 
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147 
147 
179 
99 
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148 

154 

198 
81 

183 
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130 

157 



ERASE1-PERSISTENT 

ERASE1-TENTATIVE 

ERASING 

ERROR 

EVAL 

EXHAUST 

EXPT 

EXTENSION 

EXTRACT 

PAIL 

FAIL 

FAIL PCI NT 

FIELDS 

FINALIZE 

FIND 

FOLLOWS 

FOR 



POR 

FOR- RE SOLVENT 2M 



FORK 

FRAME 

FRONT 

FUNCTION 

GtTE 

GENLOC 
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219 
218 
211 
170 
106 
235 
149 

86 
189 
112 
235 

96 
187 
231 
233 

185 * 
113 
231 
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GETC 

GIVEN 

GOAL? 
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GREATER= 

HAS 

HEAD 

HONOGENEO0S 
IDIVIDE 
/*> IN 

INC!-fEBSlSTENT 

INC!-TENT*TIVE 

INCREASING? 

INDEFINITE 

INDEX 

INDICATOB 

INITIAL 

INSEBT-FBOHT 

INSEBT-REAR 

INSTANTIATE 

INTEND 

INTENT 
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IHTEBRUPT 

INVOKE 

IS 

IS-ACTOB 

IS? 

ISOMORPHIC? 

ITOPIE 

IVECTOB 

LAST? 

LENGTH 

LESS 

L£SS= 

LIHBifi 

LIHK 

LIST ! -COM ST80CTOH 

LIST!-BECOHptfSEB t85 



LOCATIVE 

LOCK 

LOCKED? 

LOCKEB 

LOHEB 

HACBO 

HATCH 

HATCH? 

HATCHING 
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118 

105 

178 

105 

136 

143 

143 

133 

140 

186 
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183 

157 

142 



134 
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154 
78 
106 
105 
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MAX 

HEMBEB? 

HIN 

MONAD 

MONAB? 

MONITOH 

NAME 

NEXT 

NEXTCH 

NODEI-CONSTBUCTOB 

NODE !-DECOPO SEE 

NON 

NOT? 

NOMBEB 

OBLIST 

OP 

OF-TYPE 

ON 

OPTIONS 

OB 

OB? 

OVEBAii 

PEBSIST 

PEBSISTBNT 

PNAHE 
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150 

142 
150 
183 

130 

164 

171 

133 

157 

145 

186 

177 
93 

186 

156 

182 
191 
157 
181 

92 

92 
294 
232 
100 
146 
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POP 

POET 

POHEB 

PRECEDES 

PRIMARY 

PRIN1 

PRINC 

PRINT 

PROCBIND 

PROCEDURE 

PROCESS 

PROCNAHE 

PRODUCT 

PRODOCT-OF 

PROG 

PROTECT 

PROTECTION 

PUSH 
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PUT! -PERSISTENT 

PUT! -TENTATIVE 
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110 
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PUTLCCS-PEBSISIENT 
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PUTRESTS-PERSISTENT 138 



POTREST! -TENTATIVE 

QOOTE 

READ 

READCH 

REAR 

REPEAT 

REPLACE 

RESOLVE 

REST 

RESTORE 

RETRACT 

RETRY 

RING 

RULE 

SELECT 

SET-ALABK 

SET-TIMER 

SHARE 

SIGH ED-BITS 

SI HI LAB? 

STACK 

STAB 

STATE 

STEP 
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STOP 
STORAGE 



STRING !- CONSTRUCTOR 



STRUCTURE 



SQBGOAL 
SUBSTITUTE 
SUB-OF 
SUPPRESS 



SWITCH 

SWITCH 

TAIL 

TEHPCRARY 

TEHPORIZE 

TEHPBCG 

TERMINATE 



TRAILER 

TYPE 

TIPE-VECTOR 
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128 
166 



STRAIGHTEN 103 

STRAIGHTEN-UP 104 
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STRING I-DECOHICSER 185 



182 



STRUCTURE? 129 



225 
141 
188 
106 



SUSPEND 128 



228 
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134 
101 
102 
227 
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UNEXTEND 86 

UNFALSE 91 

UNIQUE 230 

UNIQUELY? 141 

UNIQUIZE 140 

UNLOCK 170 

UNHONITOR 166 

UNPRCTECT 163 

UNSET-ALABfl 90 

UNSET-TIMEB 90 

UNSBARE 144 

UPDATE 226 

UPPER 154 

VALUE 151 

VARIABLES 239 

VECTOBI-CONSTRUCTOR 145 

VECTOR I-DECOBPCSER 185 

VEL 177 

WAIT-CALL 126 

WAIT-GET 132 

WHEN 179 
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